Connect. Secure. Manage.
Meraki SD-WAN Troubleshooting
Investigate Meraki Auto VPN and SD-WAN faults through tunnel status, routing, upstream connectivity and application-path evidence.
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 troubleshooting investigates the path between a user, the MX appliance, available internet services and the application destination. Dashboard visibility is useful, but a green device status does not prove that every route, VPN or policy is correct. MCI Network Services helps customers isolate the failing part of a Meraki WAN and make controlled changes supported by evidence rather than repeatedly rebooting equipment or removing security rules.
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.
Start with the affected workflow
We identify the sites, users and applications involved, including when the problem occurs and whether it is consistent or intermittent. A branch unable to reach one private server needs a different investigation from a site with no internet access. A working comparison can reveal whether the common factor is a route, policy, circuit or endpoint.
Recent changes are recorded before diagnostics alter the state. Firmware updates, template edits, provider work and new VPN networks can all influence behaviour. Preserving event history and relevant counters helps explain an intermittent issue that might disappear temporarily after a restart without its cause being resolved.
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
Separate dashboard access from traffic forwarding
Cloud-management reachability and the paths carrying user traffic are related but distinct. We check the appliance's uplinks, local interfaces and actual application flows rather than drawing a conclusion from one dashboard indicator. A device may be managed while a VPN path is unavailable, or have a management problem while some local forwarding continues.
We also review the upstream network. NAT, provider equipment and another firewall can affect the MX's connections. The investigation compares the intended handoff with the addresses and routes actually in use, including any change introduced by a replacement modem or provider maintenance.
A useful starting point
Not sure where to start?
Bring the requirement. We will help you define the engineering work.
Follow VPN and routing state
For private-network failures, we examine tunnel availability, advertised networks and the selected route. The relevant Meraki routing behaviour is checked for the operating mode and firmware involved. We do not assume that a route visible in one part of dashboard is necessarily the path used by the affected flow.
Return traffic from the destination is traced as well. A central router, cloud route table or firewall may send responses away from the VPN endpoint. This is particularly important where the estate has several hubs, non-Meraki connections or overlapping address ranges. The complete path matters more than the status of one tunnel.
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 ↗Check the effective policy
Traffic preferences, VPN firewall rules, group policies and other supported controls can affect the same application in different ways. We identify which policy applies to a representative failing connection and compare it with the intended requirement. An expected security refusal should not be treated as a network fault simply because the user would prefer the connection to succeed.
Where the policy is wrong, the correction is narrowed to the actual cause. We avoid broad permits that restore one workflow while weakening separation across the estate. Temporary exceptions need approval, a defined scope and removal criteria, especially when a central change can affect multiple branches.
Investigate performance across both links
Loss, latency, jitter, congestion and packet-size issues can produce different symptoms. We compare relevant measurements with user reports and the actual path selected by policy. A circuit can be up while delivering poor quality, and a backup link can become overloaded after otherwise successful failover.
Application behaviour is included in the diagnosis. Large transfers, voice and interactive sessions do not respond identically to path changes or loss. We test representative workflows and distinguish transport quality from server performance, DNS or authentication delays beyond the network boundary.
Observe failover and restoration
Intermittent incidents often appear when a preferred uplink or hub changes state. We correlate events, route selection and application interruption, then test the relevant scenario within an agreed safe window. Restoration deserves the same attention as failure because a returning path can trigger another change or reveal unstable thresholds.
For warm-spare sites, the appliance role and surrounding LAN and WAN topology are examined separately. A pair changing roles repeatedly may reflect a dependency or cabling problem rather than a defect in the application. Each diagnostic change is tied to a hypothesis so the evidence remains interpretable.
Close the incident with a durable result
The final record identifies the cause, the evidence and the correction, including any provider or vendor action still outstanding. Diagnostic captures and logs are handled through a restricted process because they may contain sensitive network or user information. Unconfirmed possibilities are not presented as established faults in an escalation.
MCI can undertake a focused investigation or review recurring problems in an existing Meraki SD-WAN estate. Provide the affected workflow, approximate times and recent changes first. We can then agree the access and evidence needed to isolate the issue without asking for unnecessary secrets or changing unrelated parts of a functioning network.
Technical references
- Meraki SD-WAN monitoring — Cisco / Cisco Meraki
- MX routing behaviour — 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.