Connect. Secure. Manage.
Catalyst SD-WAN Application Routing
Configure application-aware routing in Catalyst SD-WAN, checking path quality, policy precedence and behaviour when preferred links deteriorate.
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 application routing chooses traffic paths to suit agreed app needs. We plan which measurements drive those choices and what happens when the preferred path fails. Tests check supported Cisco behaviour against real use. The records help both network engineers and app owners understand why traffic moved and whether the service was maintained.
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 application requirement first
We find the apps, user locations and traffic patterns that matter to the business. Interactive voice, remote desktops, file transfers and cloud apps can respond differently to latency, jitter and loss. A single quality threshold applied to every service may produce poor decisions or unnecessary movement between links.
The assessment includes the app's dependencies and destinations. A workflow may use authentication, content delivery and other services beyond its main hostname. We avoid classifying success from one connection while related traffic takes a different path or encounters a different security policy.
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
Verify classification on the actual platform
Application policy depends on the information the chosen Cisco platform can identify and use. We check the supported software, feature set and traffic classification behaviour. Encrypted or changing app traffic may not be classified as precisely as a business label suggests. So the design includes a considered treatment for unknown or unmatched traffic.
Where source networks, destinations or other criteria provide a more dependable match, we assess them within the supported policy model. The aim is a rule that can be explained and tested, not the most elaborate classification available. Policy ownership is recorded so changes to the app or its addressing prompt a review.
A useful starting point
Not sure where to start?
Bring the requirement. We will help you define the engineering work.
Measure the paths that are available
SD-WAN measurements describe particular paths and conditions. They are not a universal measurement of the user's whole experience. We review what is being measured, how often it changes and whether it relates to the actual app destination. A healthy overlay path can still lead to a slow app service beyond the measured boundary.
We compare normal and busy-period behaviour across the available transports. Circuits may have different capacity, contention or routing characteristics. The resulting baseline helps distinguish an unsuitable threshold from a genuinely degraded link and prevents policy from reacting aggressively to conditions that are normal for a particular service.
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 ↗Set realistic preferences and fallback decisions
The policy specifies preferred paths and what should happen when none meets the desired quality. Business owners need to understand whether traffic will use a degraded route, be restricted or follow another approved option. There may be no perfect path during a widespread provider problem. So the fallback should be deliberate rather than an unexamined default.
Security inspection and return routing remain part of the decision. Moving traffic to a different exit may change its public source address or the firewall handling it. We assess those consequences before promising that path choice will be invisible to apps with stateful sessions or source-address restrictions.
Avoid unstable policy behaviour
Thresholds that sit too close to normal variation can cause repeated changes and poor user experience. We review the supported timing, measurement and recovery behaviour, then test the policy under representative conditions. The aim is to respond appropriately to meaningful degradation without treating every brief fluctuation as a reason to move traffic.
Policy interactions are checked as well. Central rules, local preferences and other routing decisions can influence the same connection. We document their intended relationship and investigate the effective path rather than assuming the most recently edited rule is the one controlling production traffic.
Validate with application-level tests
Acceptance includes representative workflows before and after policy app, with agreed degradation or failure scenarios where safe. We observe path choice, app behaviour and restoration. A platform counter showing that traffic moved does not prove that the user experienced an improvement or that current sessions remained usable.
The test record identifies what was measured and which conditions were simulated. Where the app cannot be exercised fully, that limitation remains visible. We also confirm that unrelated traffic retains its intended treatment, so improving one important service does not unexpectedly consume the capacity another service needs.
Give operations a way to explain the decision
The handover includes policy intent, classification criteria, thresholds and expected fallback. Monitoring should help engineers determine whether an incident reflects transport quality, app performance or a policy choice. This is especially important when users report a slow service while every circuit remains physically up.
MCI can design new policies or investigate a current Cisco Catalyst SD-WAN estate that is not delivering the expected app experience. Share the important workflows, circuit mix and observed symptoms. We can build an evidence-based routing scope without promising that SD-WAN can repair inadequate capacity, provider outages or app faults outside its control.
Technical references
- Cisco Catalyst SD-WAN design guide — 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.