Connect. Secure. Manage.
Catalyst SD-WAN Architecture
Design Cisco Catalyst SD-WAN around site types, application paths, control components and an agreed model for security and operational ownership.
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 architecture explains how central services, edge devices and transport links work together. We plan routes, access boundaries and recovery before the build starts. The design follows each site’s needs and gives the team clear support duties. Central control should make those decisions easier to manage, not hide new complexity.
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.
Translate business requirements into site roles
We classify sites by what they do and the services they host. A small branch, a regional office, a data centre and a cloud setup can require different network access and failure behaviour. The architecture records those differences instead of forcing every location into one standard design with growing exceptions.
Application paths are mapped alongside site roles. We identify traffic to private systems, public services and external organisations, including any connections with strict latency, security or provider needs. This gives the design a basis for deciding where traffic should go and what must remain available when a transport or site fails.
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
Choose the control and management deployment model
We establish the supported placement and operation of Catalyst SD-WAN management, control and orchestration components. Connectivity, certificates, admin access and platform resources are considered together. The chosen model must fit the customer's duties and support arrangements, including which functions a service provider operates on its behalf.
Resilience is assessed by dependency rather than by counting components. Several instances may still share a cloud region, identity service or management path. We identify those common dependencies and explain the consequences of their loss, distinguishing effects on setup, control network access and current forwarding where the supported platform behaviour differs.
A useful starting point
Not sure where to start?
Bring the requirement. We will help you define the engineering work.
Design the transport underlay honestly
Internet, private WAN and cellular services can provide different cost and performance characteristics. We review the availability, addressing, provider equipment and contractual constraints of each transport. The architecture does not assume that two circuits ordered from different resellers necessarily use independent physical paths.
Capacity is considered in both normal and degraded operation. A low-cost backup may keep a site connected while being unable to carry every app at its usual quality. We set out traffic priorities and acceptable reduced-service behaviour so failover is measured against a realistic aim rather than an expectation that all links are interchangeable.
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 ↗Establish routing and segment boundaries
The design specifies site addressing, service-side routing, route advertisement and the permitted relationships between logical segments. Shared services and central security functions need clear treatment. A segment that is separate inside the overlay may still become reachable through an unrestricted route or firewall policy at another boundary.
We also assess interaction with current routing domains. During migration, static routing, OSPF or BGP may exchange reachability with the SD-WAN setup. Those exchanges need filters, ownership and removal criteria for temporary arrangements. The final topology should not depend on undocumented redistribution introduced during the first site cutover.
Define policy with operational consequences in mind
Central policy can affect many sites. So the architecture specifies the intended traffic treatment before rollout details are chosen. Application classification, preferred paths, quality thresholds and security inspection are linked to business needs. We explain where the platform can make a supported decision and where another component remains responsible.
Policy exceptions receive a defined scope and owner. A specialist app or provider handoff may legitimately require a different path. But that exception should be visible in the design. Hidden exceptions make later template changes and incident diagnosis much harder, especially when similar-looking sites behave differently.
Plan onboarding, migration and rollback
The architecture includes a practical sequence for bringing sites into service. We identify device preparation, transport prerequisites, certificate and identity dependencies, and the local access needed if onboarding fails. Remote setup cannot solve a missing circuit or an upstream device blocking the required network access.
A staged migration plan defines coexistence with the old WAN and the point at which each app path changes. Rollback includes routing, security and local-site dependencies, not only restoring an edge setup. We select pilot sites that represent the difficult needs so the design is tested before the rollout becomes routine.
Produce an architecture that can be operated
The deliverables include diagrams, site patterns, addressing and routing policy, failure scenarios and an ownership matrix. They also identify the tests needed to check the design and any assumptions still awaiting provider or app confirmation. Unverified assumptions are not presented as established platform capability.
Our Cisco Catalyst SD-WAN services can take the architecture into rollout or review a design prepared by another team. MCI's role is to make the choices and their consequences clear: which services the network supports, how it recovers and who manages change. That is the foundation for a WAN that remains understandable after the project team has handed it over.
Technical references
- Cisco Catalyst SD-WAN design guide — Cisco / Cisco Meraki
- Catalyst SD-WAN system overview — 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.