Connect. Secure. Manage.
Catalyst SD-WAN Troubleshooting
Investigate Catalyst SD-WAN control, tunnel and application-path faults using policy, routing and performance evidence from the affected sites.
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.
Catalyst SD-WAN troubleshooting checks whether a fault comes from transport, control, routes or policy. We start with the service users have lost and collect evidence from the relevant layer. A branch may show online while one app fails. Any live change is scoped to the finding, to avoid spreading a local problem across other sites.
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.
Define the affected service and scope
We establish the sites, users, segments and apps involved, together with the time and pattern of the problem. A failure affecting one destination from one branch needs a different investigation from a loss of all overlay network access. Working comparisons help identify whether the common factor is a circuit, device role, policy or app dependency.
Recent changes are recorded before remediation begins. Upgrades, configuration-group changes, provider work and new route advertisements can all alter behaviour. The investigation preserves useful evidence where possible rather than clearing sessions and counters immediately, which can remove the information needed to understand an intermittent fault.
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
Check the underlying transports
The overlay depends on usable network access beneath it. We review physical interfaces, addressing, provider handoffs, reachability and observed loss or latency. A circuit can be physically up while carrying traffic poorly or failing to reach the required endpoints. We compare the measurements with the service the provider is expected to deliver.
NAT, firewalls and other intermediate devices may influence connection establishment or stability. We trace those dependencies and coordinate with their owners where necessary. Removing a local policy without understanding an upstream restriction is unlikely to provide a durable fix and may weaken protection without solving the fault.
A useful starting point
Not sure where to start?
Bring the requirement. We will help you define the engineering work.
Examine control and device identity
We inspect the relevant management, control and orchestration relationships for the affected edges. Certificates, time, device authorisation and software compatibility are considered alongside network reachability. A control connection failure should not be treated as a routing-policy issue until the trust and transport prerequisites have been checked.
The platform's reported state is interpreted in context. Different component failures can have different effects on administration, learned information and current forwarding. We compare observations with the supported behaviour of the deployed release rather than assuming every dashboard warning means all app traffic has stopped.
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 ↗Trace routes and segment membership
For an unreachable destination, we follow the prefix from its source through advertisement, policy and installation at the receiving edge. We check the relevant routing context and next hop, including service-side protocols and any redistribution boundary. A route present in one table may not be available in the segment used by the affected app.
Return traffic is examined as carefully as the forward path. Stateful firewalls, shared services and cloud gateways can expose asymmetry that is not obvious from the originating edge. The investigation connects routing evidence with actual forwarding tests rather than treating a visible prefix as proof of a complete working path.
Determine the effective traffic policy
Application routing, preferred transports and other policies can override a simple expectation about the shortest path. We find the classification applied to the affected flow and the policy decision that follows. An app may be taking a deliberate fallback path because no transport meets the configured quality threshold.
We compare that behaviour with the customer's intended outcome. Incorrect thresholds, overlapping rules or an unsuitable classification can produce avoidable instability. Changes are scoped to a supported hypothesis and tested against affected and unaffected traffic, rather than removing central policy broadly until the symptom disappears.
Investigate performance with representative evidence
Latency, loss, jitter, packet size and device resource use can affect different apps in different ways. We collect relevant measurements and correlate them with user reports and provider events. A single throughput test is not enough to explain an intermittent voice problem or a session that fails after a path change.
Captures and diagnostic exports are collected under an agreed scope because they can contain sensitive network and user information. We find the evidence needed for a vendor or provider escalation and separate confirmed findings from unresolved possibilities. A useful escalation allows another team to reproduce or check the observation.
Resolve the cause and update the operating record
The final change is checked against the original failure and any relevant recovery scenario. Temporary routes, diagnostic permissions and emergency exceptions are removed or clearly accepted with an owner. The incident record explains the cause, the supporting evidence and any remaining action.
MCI can support a focused incident or review recurring problems in a wider Cisco Catalyst SD-WAN estate. Provide the affected workflow, site information and approximate times first. We can agree access and diagnostic scope without asking you to distribute unrestricted production settings or make disruptive changes before the likely fault boundary is understood.
Technical references
- Cisco Catalyst SD-WAN design guide — Cisco / Cisco Meraki
- Catalyst SD-WAN configuration consistency — 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.