Cisco SD-WAN Design: Three Decisions Before Rollout

We recommend a top-down design approach for Cisco SD-WAN: start with a high level design (HLD) that frames scope and control architecture, then move into a low level design (LLD) that specifies device templates and policy detail. The fabric centres on four functional planes, orchestration, management, control and data, built on the Cisco Catalyst 8000 portfolio. Three decisions matter early: policy model, controller placement and onboarding readiness.

TL;DR:

Fix segmentation boundaries, application SLA classes, and centralized versus local policy enforcement during HLD; only one centralized data policy per site per direction is supported.

Order transport circuits and hardware while LLD work proceeds, and submit certificate requests concurrently, because delivery and site readiness often delay deployment.

Automated onboarding differs by device: PnP serves IOS XE platforms, while ZTP supports vEdge; both require a whitelist and trusted certificate chain.

Choose hub and spoke for concentrated traffic, full mesh for direct site reachability, or hierarchical regions when control connections need distribution at scale.

Keep pilots bounded with acceptance criteria, one hub and two spokes, and validate firewall access, CA trust, underlay reachability, tunnels, and OMP routes before signoff.

Re-solution

re-solution.co.uk

Plan Your Cisco SD-WAN Rollout

Re-solution provides Cisco network solutions and infrastructure audits to help organisations shape connectivity around their needs.

Explore Cisco network solutions

Architecture overview: planes, OMP and core concepts
Key platforms and device choices in the Catalyst 8000 portfolio
Design methodology: high level design then low level design
Policy and segmentation: centralised and localised policy, application aware routing
Onboarding and provisioning: Plug and Play, ZTP, bootstrap and staging
Deployment models, topologies and controller scaling
Templates, configuration groups and operational workflows
Migration and deployment checklist for pilots and rollout
Lessons from practice: what actually speeds up a project
How we can help with your Cisco SD-WAN design
FAQ
Sources

Architecture overview: planes, OMP and core concepts

Cisco Catalyst SD-WAN architecture is defined by four functional planes. The orchestration plane (SD-WAN Validator) authenticates devices and brokers their first contact with the fabric. The management plane (SD-WAN Manager) handles central configuration, monitoring and policy authoring. The control plane (SD-WAN Controller) distributes routes, next hops, encryption keys and policies using Overlay Management Protocol (OMP), and the data plane, made up of WAN Edge routers, carries application traffic across encrypted tunnels. Separating control from data is what lets the Cisco Catalyst SD-WAN design guide describe a fabric that scales without per-site manual key exchange.

Within this model, three VPN types matter: transport VPN (underlay connectivity), management VPN (out of band access) and service VPNs (the segments carrying user traffic). Each WAN Edge interface is also tagged with a TLOC, a combination of system IP, colour and encapsulation that identifies a transport path. Colour labels (such as biz-internet, mpls or lte) let policy distinguish one circuit from another without touching the underlying routing.

Key platforms and device choices in the Catalyst 8000 portfolio

Platform choice should follow role, not preference. The Catalyst 8000 hardware family, spanning the C8200, C8300 and C8500, covers branch, aggregation and data centre roles, while Catalyst 8000V consolidates earlier CSR1000V and ISRv capability into a single virtual platform for on-premises or cloud deployment. All run the same IOS XE SD-WAN software, which keeps feature parity consistent across hardware and virtual instances and supports Plug and Play (PnP) for automated provisioning.

Sizing decisions at this stage should account for expected control connection counts per device, TLOC and tunnel counts per site, and the throughput and feature set each role demands. A small branch with two transports needs far less head end capacity than an aggregation site terminating hundreds of spoke tunnels, and that difference should shape hardware selection before procurement begins.

Design methodology: high level design then low level design

HLD and LLD serve different purposes and should never be merged into one document. The SD-WAN small branch case study frames HLD as the stage where site counts, transport choices, platform selection and the control component deployment model get fixed, along with a pilot plan and its acceptance criteria.

LLD then takes each HLD decision and makes it buildable: site profiles, template variables, routing protocol and QoS detail, certificate issuance plans and firewall specifics all belong here. Keeping that separation disciplined, rather than letting LLD detail creep into HLD meetings, is what shortens the overall project calendar.

Lead times vary by site readiness. Transport circuit ordering and hardware delivery, documented in the SD-WAN end-to-end deployment guide, are frequent causes of schedule slip and should be ordered in parallel with LLD authoring rather than after it. Teams that run procurement, certificate requests and template build concurrently typically compress calendar time without changing the sequence of decisions.

Policy and segmentation: centralised and localised policy, application aware routing

Cisco Catalyst SD-WAN splits policy into two layers. Centralised control and data policies are authored on the SD-WAN Controller and pushed to the fabric to enforce consistent overlay behaviour: control policy shapes OMP route distribution, while centralised data policy can apply 5-tuple matching across the whole fabric, though the Catalyst SD-WAN policies configuration guide notes that only one data policy per site per direction is supported. Localised policies run on the edge device itself, covering interface QoS, access lists and site level routing protocol interaction with BGP or OSPF, as set out in the localised policy guide.

VPN membership policy controls which segments a site can reach, while application aware routing (AAR) measures loss, latency and jitter per tunnel and steers traffic into SLA classes defined for each application. At HLD stage, architects should decide segmentation boundaries, which applications need guaranteed SLA classes and whether centralised or localised enforcement fits each requirement, rather than leaving that choice to LLD.

Onboarding and provisioning: Plug and Play, ZTP, bootstrap and staging

Onboarding method depends on platform and operational control needs. The WAN Edge onboarding deployment guide describes Plug and Play (PnP) as the automated path for IOS XE devices, discovering the Validator address with no manual configuration, while Zero Touch Provisioning (ZTP) serves the equivalent role for vEdge devices. Bootstrap files and manual onboarding remain options where automated discovery is not available.

Secure onboarding depends on two prerequisites: a device whitelist, imported into SD-WAN Manager as a provisioning file, and a working certificate trust chain between device and controllers. A staging state lets a device establish control connections before its data plane goes live, useful for validating connectivity ahead of cutover. Required firewall ports, NAT behaviour and certificate renewal should all be checked before rollout: our security checklist covers the common gaps teams miss at this stage.

Deployment models, topologies and controller scaling

Topology choice is driven by tunnel count and head end capacity. Hub and spoke concentrates tunnels at a small number of aggregation sites and suits centralised traffic patterns; full mesh gives every site direct reachability but multiplies tunnel count quickly; hierarchical or multi-region fabrics divide large networks into manageable domains with their own control component groups.

The large global WAN case study describes controller groups and affinity rules as the mechanism for distributing control connections at scale, rather than concentrating every device on a single controller pair. TLOC colour restriction, limiting which colours can form tunnels with each other, is a practical way to cut unnecessary tunnel state at head ends without losing redundancy. Our failover design playbook sets out how these choices interact with resilience planning.

Templates, configuration groups and operational workflows

Device and feature templates turn LLD decisions into deployable configuration. Feature templates define reusable settings, such as interface or routing parameters, while device templates assemble them per platform role; variables then map each template to a specific site profile without hand editing every device. Configuration groups extend this model for newer SD-WAN Manager releases, grouping related templates for consistent rollout.

Policy attachment, staged template pushes and software upgrade sequencing should all appear as explicit steps in LLD, not assumptions. Validation checks worth including: confirming tunnel establishment, OMP route counts and interface status before marking a site complete.

Migration and deployment checklist for pilots and rollout

A disciplined pilot keeps the first live sites representative without over-scoping. We recommend fixing pilot duration and a minimum site profile before work starts, then testing against it.

Define pilot scope and acceptance criteria covering at least one hub and two spoke sites.
Confirm firewall ports, serial numbers and whitelist entries are staged ahead of shipping.
Validate root CA trust and underlay reachability before any device reaches the field.
Check TLOC counts, QoS queue design, LTE failover strategy and tunnel limits per site profile.
Hand over monitoring dashboards, runbooks and agreed upgrade windows at pilot close.

Pro Tip: Lock the pilot acceptance criteria in the HLD document itself, so sign-off does not drift once LLD work begins.

Our pilot architecture and checklist guide sets out a six to ten week pilot structure that many of these checks are drawn from.

Lessons from practice: what actually speeds up a project

Projects slow down for predictable reasons: pilots that grow beyond their original scope, templates rebuilt per site instead of reused, and firewall or certificate requests raised too late to clear security review in time. Fixing any one of these early removes weeks from a typical rollout.

One recurring fix is simple: treat TLOC colour restriction as a default design choice at hub sites rather than an afterthought, which avoids a later redesign once tunnel counts climb. Our pilot and pricing guide sets out scoping detail worth reviewing before committing to a pilot date.

— Jacob

How we can help with your Cisco SD-WAN design

We have experience covering HLD and LLD delivery, pilot architecture and ongoing SD-WAN operation. Where a design needs an outside review, we offer Professional Services for architecture and HLD/LLD work, Managed Services for ongoing operation, and Network As A Service for a subscription delivery model.

A network audit is often the most useful starting point, since it confirms underlay readiness before a pilot date is set. Get in touch through our contact page to discuss scope.

FAQ

What is SD-WAN and SDN?

SD-WAN is a software defined approach to managing wide area network connectivity across multiple transports, using centralised policy to control routing and application steering. SDN is the broader concept of separating network control logic from forwarding hardware, and SD-WAN is one application of that principle focused specifically on the WAN.

What is a Cisco router used for?

A Cisco router forwards traffic between networks and, in an SD-WAN fabric, acts as the WAN Edge device that builds encrypted tunnels across available transports. Platforms in the Catalyst 8000 portfolio fill this role in current Cisco SD-WAN designs, in hardware or virtual form.

What are the Cisco SD-WAN appliances available?

Current Cisco Catalyst SD-WAN designs are built on the Catalyst 8000 hardware family, including the C8200, C8300 and C8500, alongside the virtual Catalyst 8000V for cloud or on-premises deployment. All run IOS XE SD-WAN software with consistent feature support across the range.

How to set up an SD-WAN?

A Cisco SD-WAN deployment typically starts with an HLD that fixes scope, platform choice and control component placement, followed by an LLD covering site profiles and templates, as described in the small branch case study. Devices then onboard through Plug and Play or Zero Touch Provisioning, PnP for IOS XE devices and ZTP for vEdge devices, once whitelist and certificate prerequisites are in place.