Connect. Secure. Manage.
Meraki SD-WAN Performance Classes
Define and validate Meraki performance classes so loss, latency and jitter thresholds reflect actual application needs rather than default assumptions.
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 performance classes set quality thresholds for selected traffic on supported VPN paths. We choose and test those thresholds against the apps and links in use. The aim is to steer traffic when a path degrades without causing needless changes. Measurements need a clear meaning before they are used to drive routing decisions.
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.
Understand what the platform measures
We establish which paths and quality indicators are available in the customer's firmware, licence and topology. Latency, loss and jitter measurements describe particular network conditions. They do not on their own measure the complete app transaction. A healthy path to a remote endpoint can still lead to a slow server or another bottleneck beyond the measured boundary.
The assessment separates physical link availability from usable quality. A circuit can remain up while congestion or loss makes an interactive app difficult to use. Conversely, a brief measurement fluctuation may not justify moving traffic that is otherwise operating acceptably. The policy should reflect meaningful service impact rather than react to every variation.
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
Build a baseline before choosing thresholds
We compare normal, busy-period and known degraded behaviour across the available links. Different transports may have different characteristics, particularly when cellular or long-distance paths are involved. A threshold suitable for a local fibre connection may exclude a backup path even when it is the only reasonable way to maintain the critical service.
Application owners help define what users actually need. Voice, remote desktops and bulk transfers can tolerate different conditions. We do not assume that all traffic marked business-critical requires the same class or that a stricter numerical threshold necessarily produces a better result.
A useful starting point
Not sure where to start?
Bring the requirement. We will help you define the engineering work.
Map classes to a manageable application policy
A performance class is useful only when the relevant traffic is chosen correctly. We review the matching criteria and their supported behaviour, including traffic that cannot be classified as precisely as expected. The policy needs a deliberate default treatment for unmatched flows rather than leaving important apps to an accidental fallback.
We keep the number of classes proportionate to the genuine service differences. Too many nearly identical classes make operations harder without adding useful control. Each class should have a documented purpose and an owner who can explain the thresholds, preferred paths and accepted limitations.
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 ↗Decide what happens when no path qualifies
There may be occasions when every available path falls outside the desired quality. The customer must understand the supported fallback behaviour and the trade-off between degraded network access and no network access. A performance policy cannot create a good circuit when every transport is impaired.
We also examine the capacity available after a path change. Moving several important apps to a smaller backup link can introduce new congestion. The design considers traffic priority and demand, so quality-based steering is not assessed independently of the amount of traffic the surviving path must carry.
Check session and security consequences
Traffic movement can affect established sessions or change the path through stateful security devices. We find the apps that are sensitive to those changes and check them during the pilot. A measured improvement in path quality is not enough if the app repeatedly reconnects and becomes less usable overall.
The alternate path must also preserve the intended security arrangement. We check inspection, routing and source-address dependencies relevant to the rollout. Performance preferences should not silently bypass controls that the customer expects to apply to the same app under normal operation.
Test degradation and restoration safely
We agree a test scope that shows the policy without causing uncontrolled disruption. This may include a representative pilot site, controlled path impairment or observation of known conditions where active tests are unsuitable. The record explains the conditions used and the limits of what they prove.
Restoration is included because a recovering link can fluctuate around a threshold. We observe whether the supported behaviour is stable enough for the app and whether monitoring gives the operations team a useful explanation. Repeated path changes should be investigated, not dismissed merely because each individual decision follows the configured threshold.
Review classes as the network changes
Circuit upgrades, new providers and app changes can make an old baseline misleading. We recommend periodic review of the class assumptions and a change process for significant adjustments. Monitoring should connect quality events with app impact rather than presenting a long history of measurements with no operational interpretation.
MCI can assess current performance classes or prepare them as part of Meraki SD-WAN traffic policy work. Provide the circuit mix, important apps and the symptoms users report. We can establish a measurable, supported policy that improves use of available paths without promising that steering alone resolves every WAN or app performance problem.
Technical references
- Meraki SD-WAN best-practice design — Cisco / Cisco Meraki
- Meraki SD-WAN monitoring — 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.