UK SD‑WAN Pilot in Six to Ten Weeks: Architecture and Checklist

SD-WAN architecture separates network control from network forwarding, so a central controller sets policy while local edge routers move traffic across whatever transport is available. The core advantage is centralised, application-aware routing with forwarding still handled locally at each site. Cisco Catalyst SD-WAN is a working example of this model, using OMP to distribute routes and policy across the fabric without controllers ever touching user traffic.

TL;DR:

SD-WAN’s control plane never carries user traffic, with traffic forwarding handled locally at each site based on centrally distributed policies.

Deployments should include redundant controllers and validators across multiple regions to prevent outages and improve resilience.

Application-aware routing prioritizes traffic types like voice or backup based on real-time path health, improving overall application performance.

Most issues stem from control plane connectivity, transport health, or policy misconfigurations, making thorough diagnostic procedures essential.

Enterprises can run SD-WAN alongside existing MPLS, broadband, and LTE links, often using hybrid models to optimize costs and maintain service continuity.

Re-solution

Plan Your Network Pilot With Confidence

Re-Solution provides Cisco network solutions, infrastructure audits and network surveys for organisations planning resilient connectivity.

Explore Re-Solution

SD-WAN architecture overview: the four planes explained
Core SD-WAN components: controllers, managers, validators and edge routers
How does SD-WAN control plane vs data plane actually work?
Which SD-WAN deployment types and topologies should you choose?
Security integration: how does SD-WAN support SASE?
What design choices affect SD-WAN scaling and resilience?
How do you plan an SD-WAN pilot and rollout?
Re-Solution’s practitioner view on SD-WAN pilots
Does SD-WAN work with existing MPLS, broadband, and LTE circuits?
How does application-aware routing work in SD-WAN policy?
What monitoring and analytics does SD-WAN architecture provide?
What are the most common SD-WAN troubleshooting challenges?
Managed service or in-house: which suits your SD-WAN rollout?
Ready to scope your SD-WAN pilot?
Sources
FAQ

SD-WAN architecture overview: the four planes explained

Every credible SD-WAN architecture overview starts with plane separation, because that separation is what makes the whole system automatable. Cisco’s Catalyst SD-WAN model splits responsibility across four distinct planes, each with a narrow job.

Orchestration plane — authenticates new devices, discovers controllers and managers, and handles NAT traversal so edge routers can find their way onto the fabric with minimal manual configuration.
Management plane — the single pane for policy authoring, software lifecycle, and telemetry collection across the whole estate.
Control plane — distributes routing information, security keys, and policy decisions to every edge device, without ever forwarding a single packet of user traffic itself.
Data plane — the WAN edge routers that actually carry application traffic, encrypt it, and enforce the policy the control plane has pushed down.

This split is what Cisco’s solution overview documents formally, and it is the reason SD-WAN scales in ways traditional router-by-router WAN configuration never could. Change a policy once at the management plane and every edge device inherits it within minutes, not weeks.

That separation also gives you auditability. Because policy lives centrally rather than scattered across hundreds of router configs, you can trace exactly when a routing decision changed and why. When you look at a vendor’s architecture diagram, check that it shows all four planes with clear arrows indicating which plane talks to which. If a diagram only shows two boxes labelled “controller” and “router”, it is oversimplified for a design decision. The software-defined networking principles behind this layering apply whether you deploy on-premises appliances or cloud-hosted controllers.

Core SD-WAN components: controllers, managers, validators and edge routers

Designing an SD-WAN estate means procuring specific pieces of kit and software, not just picking a concept. Cisco Catalyst SD-WAN names these components explicitly, and mapping them to generic terms helps when you read documentation from other vendors too.

WAN Edge routers — physical appliances at branch sites or virtual instances in a data centre, colocation facility, or cloud region; these form the data plane and are the only components that forward customer traffic.
SD-WAN Controller — the control plane workhorse, running OMP, acting broadly like a route reflector, and distributing the cryptographic keys edge devices need to build tunnels.
SD-WAN Manager — the management plane, where your team authors policy, pushes software updates, and pulls telemetry for troubleshooting.
SD-WAN Validator — the orchestration plane, handling first-contact authentication and helping new edge devices discover the rest of the fabric, including NAT traversal.

Generic industry terms sometimes label these as “orchestrator”, “controller”, “manager” and “edge device” respectively, so the concepts translate reasonably well across platforms even if the branding differs.

Pro Tip: When you’re comparing quotes from different integrators, ask explicitly how many controller and validator instances they’re proposing, and where those instances sit geographically. A single-region controller design is a common shortcut that quietly increases your exposure to regional outages.

Virtual WAN edge routers deployed close to major cloud regions tend to perform better for SaaS-heavy sites, a point Cisco’s design guide makes when discussing cloud on-ramp strategy. If your estate leans on Microsoft 365 or Salesforce, the location of your virtual edges matters as much as your branch hardware.

How does SD-WAN control plane vs data plane actually work?

The control plane never carries a single byte of user traffic. That single fact resolves most of the confusion IT teams have about SD-WAN control plane vs data plane behaviour, because it’s tempting to assume the controller sits “in the path” the way a traditional core router does. It doesn’t. Controllers distribute information; edge routers act on it.

Overlay Management Protocol carries three things across the fabric: routes, next-hop information (called TLOCs, or transport locators), and the cryptographic keys edge devices need to build tunnels with each other. Those tunnels themselves run as IPsec or GRE for actual data forwarding, while the control channels connecting edge routers to controllers use DTLS or TLS.

Edge devices typically try every provisioned transport link and open a control connection to the SD-WAN Controller over each one, which is why a single site with broadband and LTE backup can survive one link failing outright.
Controllers distribute keys rather than requiring per-pair IKE negotiation between every device, an approach Cisco’s system overview describes as removing a major scaling bottleneck in large mesh deployments.
Path health is monitored continuously using Bidirectional Forwarding Detection, feeding latency, jitter, and loss data back into routing decisions in near real time.

Policy, not raw topology, decides where traffic goes. An application flagged as latency-sensitive can be steered away from a degraded path before a human ever notices the problem, purely because BFD flagged the transport as unhealthy.

Which SD-WAN deployment types and topologies should you choose?

Deployment type and topology are separate decisions, and conflating them is a common design mistake. Deployment type is about where your controllers and management plane live; topology is about how your sites connect to each other.

On-premises deployment places controllers and managers inside your own data centre, giving you full control at the cost of running the infrastructure yourself.
Cloud-enabled deployment hosts the control and management planes with the vendor or a cloud provider, reducing your operational burden while keeping edge routers on-site.
Cloud backbone or colocation-hosted deployment routes traffic through provider-owned backbone infrastructure or colocation hubs, often improving performance for geographically spread sites.

On topology, full mesh gives every site a direct tunnel to every other site, which suits organisations with heavy site-to-site traffic but scales expensively. Hub-and-spoke routes everything through a central point, cheaper to run but adding latency for site-to-site flows. Most real deployments end up hybrid, running full mesh for a handful of high-traffic sites and hub-and-spoke for the rest, often varying by VPN or segment rather than applying one topology estate-wide.

Security integration: how does SD-WAN support SASE?

Security architecture inside SD-WAN comes down to one recurring decision: inspect traffic locally at the branch, or send it back to a central point first. Direct internet access at the branch, with a local next-generation firewall doing inspection on-site, cuts latency for cloud-bound traffic dramatically compared with hairpinning everything through a data centre. The trade-off is consistency: centralised inspection makes compliance reporting simpler because every packet passes through the same policy engine.

Segmentation using VPNs or VRFs keeps guest Wi-Fi, finance systems, and building management traffic logically separate on the same physical fabric.
Per-VPN policy means a manufacturing site can apply stricter rules to its OT segment without touching policy on its office VPN.
Secure Access Service Edge functions, including CASB and DNS security, increasingly get bolted onto SD-WAN fabric as cloud-delivered services rather than on-box appliances.

Pro Tip: If your compliance team insists on centralised logging for audit purposes, you can still run local DIA breakout and stream firewall logs back centrally, so you don’t have to sacrifice latency to satisfy an auditor.

Managed SASE, where a partner runs the security stack alongside the network fabric, is worth considering if your team already stretches thin on firewall administration.

What design choices affect SD-WAN scaling and resilience?

Redundancy planning starts with your controllers and managers, not your edge routers. Running SD-WAN Controllers and Managers across at least two geographically separate sites protects you against a regional outage taking down policy distribution for the entire estate.

Transport diversity, mixing broadband, LTE, and MPLS at critical sites, gives BFD something meaningful to fail over between.
QoS policy should classify voice and video separately from bulk file transfer, since a single best-effort queue defeats much of the point of application-aware routing.
Monitor latency, jitter, packet loss, and BFD session status continuously, with alert thresholds tighter for voice traffic than for general internet browsing.

If control plane connectivity to a site is lost, edge routers don’t simply drop traffic. They keep forwarding using their last-known routing state for a configurable window, commonly for a configurable window by default in some implementations, which buys time to fix a controller issue without a branch going dark. That grace period is one of the more underappreciated resilience features in the whole architecture.

How do you plan an SD-WAN pilot and rollout?

A pilot only tells you something useful if it’s built to fail informatively, not just to prove the concept works under ideal conditions.

Select pilot sites deliberately — mix at least one SaaS-heavy office with one more traditional branch, so you see real cloud on-ramp behaviour alongside standard traffic patterns.
Define success metrics and rollback criteria upfront — application response time, failover duration, and helpdesk ticket volume during the trial window are all reasonable measures.
Map cost drivers early — edge hardware or software licensing, transport changes such as adding broadband circuits, and either professional services or managed services fees if you’re outsourcing operation.
Validate routing, failover, and SaaS experience explicitly — don’t just confirm the tunnels come up; pull an edge router’s transport link during the pilot and watch what actually happens to voice and video traffic.

Pro Tip: Run your pilot for at least one full billing cycle before deciding on rollback criteria. Some failover issues only surface under real end-of-month traffic spikes, not synthetic testing.

A realistic UK enterprise pilot runs six to ten weeks from kickoff to decision point, with IT, network, and security stakeholders all reviewing results before a phased rollout begins. A detailed migration plan and pilot template can shorten that timeline considerably.

Re-Solution’s practitioner view on SD-WAN pilots

Experienced Cisco network deployment practitioners provide pilot design and failover testing based on decades of live infrastructure work rather than theory. Sector deployments across manufacturing and logistics sites have shaped a pragmatic approach to SD-WAN failover design, particularly around transport diversity for sites where downtime carries real operational cost. Pilots are scoped around measurable rollback criteria from day one, and managed operation picks up cleanly once a design is validated.

Does SD-WAN work with existing MPLS, broadband, and LTE circuits?

SD-WAN was built to run alongside existing WAN technologies, not replace them overnight, and that interoperability is one of the strongest practical reasons enterprises adopt it. An edge router treats MPLS, broadband, and LTE simply as transport options, each becoming a TLOC that the control plane can route policy across.

MPLS circuits already in place under existing contracts don’t need to be ripped out. Many organisations run SD-WAN in a hybrid mode for years, keeping MPLS for latency-sensitive traffic like voice while shifting bulk internet-bound traffic to broadband, cutting circuit costs without touching service continuity on critical applications. This is often the single biggest financial driver behind adoption, since MPLS pricing per megabit dwarfs broadband pricing at most UK sites.

Broadband integration is more straightforward still, since most WAN edge appliances ship with multiple WAN ports specifically to support consumer-grade or business broadband alongside a primary circuit. LTE, and increasingly 5G, tends to serve as a backup transport rather than a primary one, activated automatically when BFD flags the primary paths as degraded.

The practical complication isn’t technical compatibility so much as contractual timing. MPLS contracts often run three or five years, and unwinding one early can trigger early-termination charges that erase much of the savings SD-WAN was meant to deliver. A sensible interoperability strategy usually means running SD-WAN over the existing MPLS estate first, adding broadband circuits as new sites come online, and letting old MPLS contracts lapse naturally rather than forcing an early exit.

How does application-aware routing work in SD-WAN policy?

Application-aware routing is the feature most IT teams actually bought SD-WAN for, even if they described it as “better WAN performance” during procurement. The principle is simple: instead of routing every packet by destination address alone, the fabric identifies which application generated the traffic and applies a routing policy specific to that application’s needs.

A voice-over-IP call gets classified differently from a large file backup, even if both originate from the same office and head to the same data centre. The policy engine, running centrally through the SD-WAN Manager, defines rules such as “voice traffic prefers the lowest-latency path available, regardless of cost” or “backup traffic prefers the cheapest path, regardless of latency.” Those rules then get pushed down to every edge router, which applies them locally without needing to phone home for every packet.

This is where the plane separation covered earlier pays off practically. Because policy is centralised, a change made once, say tightening the latency threshold for a newly added video conferencing platform, propagates across every site within minutes rather than requiring someone to touch each branch router individually.

Network policies typically layer three things: application identification (often via deep packet inspection or known port and protocol signatures), path preference rules tied to real-time BFD health data, and fallback behaviour for when a preferred path becomes unavailable entirely. Get the fallback behaviour wrong, and a policy that looks perfect on paper will silently degrade user experience the first time a preferred circuit has a bad day.

What monitoring and analytics does SD-WAN architecture provide?

Centralised telemetry is one of the clearer operational wins of adopting SD-WAN over a traditional router-by-router WAN, because every edge device reports back to the same management plane rather than scattering logs across dozens of separate device consoles.

The SD-WAN Manager aggregates path-level data, including latency, jitter, and packet loss per transport link, alongside BFD session status showing exactly when a path was marked unhealthy and for how long. That data feeds dashboards showing application performance across the entire estate from a single screen, rather than requiring a network engineer to log into each branch router individually to diagnose a slow SaaS connection.

Analytics extend beyond simple uptime reporting. Because the fabric already classifies traffic by application for routing purposes, that same classification data becomes useful for capacity planning, showing which sites are approaching bandwidth limits on specific application categories well before users start complaining. Historical trend data also helps justify transport changes to finance teams, since you can show precisely how much traffic shifted from an expensive MPLS circuit onto broadband after a policy change.

For IT teams managing compliance obligations, this centralised visibility matters as much as the performance benefits. Audit trails showing policy changes, device onboarding events, and security posture across every site sit in one place rather than needing reconstruction from scattered logs after an incident. That consolidated view is part of why plane separation, covered earlier in this piece, delivers real operational value rather than just architectural tidiness.

What are the most common SD-WAN troubleshooting challenges?

Most SD-WAN troubleshooting problems trace back to one of three areas: control plane connectivity, transport health, and policy misconfiguration, and distinguishing between them quickly saves significant diagnostic time.

Control plane connectivity issues typically show up as an edge device failing to establish its DTLS or TLS session with the controller, often caused by firewall rules blocking the required ports or NAT traversal failing during initial onboarding through the validator. Checking whether a device has successfully authenticated through the orchestration plane is usually the first diagnostic step, before assuming a hardware fault.

Transport health problems are where BFD earns its keep, but also where teams sometimes misread the data. A path showing intermittent BFD flaps isn’t necessarily a failing circuit; it can equally point to a saturated link during peak hours, which looks identical to packet loss from the routing layer’s perspective. Pulling raw interface statistics alongside BFD status avoids misdiagnosing a capacity problem as a hardware fault.

Policy misconfiguration tends to be the hardest to spot because the network itself appears healthy. Traffic reaches its destination, just via the wrong path or with the wrong priority, so nothing throws an obvious error. Reviewing application classification rules against actual observed traffic patterns, rather than assuming the policy authored months ago still matches current application usage, catches most of these issues before they escalate into user complaints.

Managed service or in-house: which suits your SD-WAN rollout?

Managed delivery suits teams without dedicated network engineers or with multiple unpredictable sites. In-house delivery suits organisations with strong existing Cisco skills and predictable, centralised procurement cycles. Support responsiveness should weigh as heavily as licence cost in that decision.

— Jacob

Ready to scope your SD-WAN pilot?

If you’ve read this far, you already know SD-WAN isn’t a single box you buy, it’s an architecture decision that touches procurement, security, and day-to-day network operations for years afterwards. Re-solution has spent over 35 years as a Cisco partner turning that kind of decision into a working network, and that experience covers exactly the pilot-to-rollout path this article has walked through.

Whichever stage you’re at, there’s a service that matches it. If you need architecture and pilot scoping done properly, Professional Services covers design and procurement support directly. If you’d rather hand ongoing operation to a partner once the design is proven, Managed Services takes on monitoring and SLA delivery, and Network As A Service packages SD-WAN as a subscription rather than a capital purchase. Before any of that, a network audit establishes the baseline your pilot will actually be measured against. Get in touch through the contact page to scope a pilot or request an audit before you commit to a design.

Sources

For deeper technical detail, consult Cisco’s SD-WAN design guide and the Cisco SD-WAN eBook. Re-Solution’s failover design playbook covers pilot templates in more depth.

Cisco Catalyst SD‑WAN solution overview

FAQ

Is SD-WAN obsolete?

No. SD-WAN adoption continues to grow because it solves a problem traditional WAN architecture never addressed well: routing traffic by application need rather than fixed topology alone. It remains the standard approach for organisations blending MPLS, broadband, and LTE across multiple sites.

What is SD-WAN for dummies?

SD-WAN separates network control from network forwarding: a central system decides policy, while local routers at each site actually move traffic across whatever internet or private links are available. Think of it as a satnav for your network traffic, constantly rerouting around problems rather than following one fixed road regardless of conditions.

Which is better, SD-WAN or MPLS?

Neither replaces the other outright; most enterprises run both together. MPLS still suits latency-critical traffic under strict SLAs, while SD-WAN adds broadband and LTE into the mix for cost savings and resilience, with application-aware routing deciding which traffic uses which path.

What are the key differences between SD-WAN and a traditional WAN?

Traditional WAN routes traffic based on fixed topology and manual router-by-router configuration. SD-WAN centralises policy through a management plane and pushes application-aware routing decisions to edge routers automatically, cutting configuration time and improving failover response.

How much does an SD-WAN pilot cost with Re-solution?

Costs depend on site count, hardware needs, and whether you choose Professional Services or ongoing Managed Services, so pricing is scoped per project rather than published as a flat rate. Current details are available directly through Re-solution’s services pages.