SD-Access Design: A Planning Guide for UK Network Teams

A good SD-Access design starts before any hardware is ordered. It begins with an inventory of users, devices and traffic flows, moves to a decision on how many fabric sites you need and where the border, control plane and edge roles sit, and ends in a documented high-level design (HLD) that your operations team can run. This guide covers the decisions in the order we take them, with the pitfalls that most often cost UK campus, school, factory and warehouse networks time.

It is written for IT directors and network leads weighing a Cisco Software-Defined Access (SD-Access) deployment, whether you build it yourself, with a partner or as a managed service.

TL;DR

• SD-Access is a routed underlay with a virtual overlay, managed from Cisco Catalyst Center and enforced through Cisco ISE policy. Design the fabric site, the node roles and the policy model together, not one after another.
• Discovery comes first. Automation applied to an unknown estate reproduces its mistakes at speed.
• Segment by risk profile: virtual networks for macro-segmentation, security group tags for micro-segmentation, and device posture signals from ISE alongside identity.
• Plan DHCP, wireless and transit to other sites explicitly. They are the most common sources of late surprises.
• Keep a current HLD. Cisco support can ask for one at any time.

Table of Contents

• What SD-Access design actually covers
• Start with discovery, not topology
• Fabric sites: how many, and where
• Segmentation: design it by risk, not by department
• Policy rollout: monitor, then enforce
• DHCP, wireless and the details that cause late delays
• Document the design: the HLD
• What benefits to expect, and what to treat with care
• Sector considerations
• Our perspective
• Where we can help
• FAQ
• Sources

What SD-Access design actually covers

SD-Access combines Cisco Catalyst Center, ISE and fabric-capable wired and wireless platforms. The wired and wireless devices form the fabric, and ISE provides central policy. Design work therefore splits into four layers:

1. Underlay: the routed network that carries traffic between fabric devices.
2. Overlay: the virtual networks, IP pools and anycast gateways users and devices attach to.
3. Policy: who or what may talk to what, expressed as groups rather than IP addresses.
4. Management: Catalyst Center workflows, ISE nodes, and the assurance data you rely on to run it.

A design that handles only the overlay and leaves the underlay as inherited is the most frequent cause of rework we see in the sector.

Start with discovery, not topology

The shift to SD-Access is as much an operating change as a technical one. Teams move from configuring box by box to describing intent and letting the controller apply it. That only works if you know the estate. NCSC guidance on zero trust network access is built around understanding your architecture, and the same discipline applies here.

Before drawing a fabric, collect:

• Users and roles: staff, students, contractors, guests, shift workers.
• Endpoints: managed laptops, unmanaged devices, printers, building controls, cameras, handheld scanners, production-line equipment.
• Applications and flows: what each group genuinely needs to reach, including legacy systems that cannot support modern authentication.
• Existing wiring and switching: closet locations, uplink capacity, switch models and software versions, and which are fabric-capable.
• Sites and links: campuses, buildings, remote offices and the WAN between them.

A structured network audit is the quickest way to get this baseline, and our network audit checklist shows what evidence to gather for each finding.

Fabric sites: how many, and where

In Cisco’s design model, a fabric site is a location with its own border node, control plane node and edge nodes. For wireless, a fabric-mode wireless controller is dedicated to that site. This definition drives most layout choices.

One large site or several small ones

A single fabric site is simpler to run and gives users seamless mobility across it. Multiple sites limit the failure domain and suit geographically separate premises. As a working guide:

Treat this as a starting position. Scale limits and latency requirements for Catalyst Center and ISE decide the final answer, and the Cisco Live planning material lists requirements gathering and deployment-wide scale considerations as the first step of any plan.

Node roles

• Edge nodes connect users and devices. They are usually your access switches.
• Control plane nodes hold the endpoint-to-location mapping. Cisco builds this role on LISP, combining map-server and map-resolver functions. Plan at least two for resilience.
• Border nodes connect the fabric to everything outside it: the data centre, internet, WAN and other sites. Decide early whether each border handles internal, external or both.
• Intermediate nodes are the routed devices in between that carry underlay traffic and do not need fabric intelligence.
• Extended nodes and fabric in a box cover small closets and small sites where a full three-role design would be excessive.

Keep the underlay deliberately plain: point-to-point routed links, consistent addressing, no clever exceptions. Every exception becomes a support call later.

Segmentation: design it by risk, not by department

SD-Access offers two tiers of separation. Virtual networks (VNs) provide macro-segmentation: separate routing contexts that do not communicate unless you deliberately allow it. Security group tags (SGTs) via Cisco TrustSec provide micro-segmentation inside a VN.

NCSC’s guidance stresses that segmentation is central to zero trust and that applications should be grouped by risk profile, so critical business services are isolated from low-risk public or guest services and the potential for lateral movement shrinks. That translates directly into a VN plan:

• Guest VN: internet only, no route to internal resources.
• Corporate VN: managed users and devices, with SGTs for role-based rules.
• IoT and building systems VN: cameras, access control, HVAC, signage, with narrow, documented flows.
• Operational technology VN (manufacturing): production systems kept apart from office traffic, with controlled data exchange.
• Payment or regulated-data VN: where a regulator or auditor requires demonstrable isolation.

Resist creating a VN per department. Each VN adds routing, firewall and troubleshooting overhead. Use VNs for hard trust boundaries and SGTs for role differences within them.

Identity is not the whole decision

TrustSec gives granular control, but it should not be your only control. Effective designs feed ISE with context such as device health and behaviour, and keep re-evaluating the session. A design that grants access on identity alone has a gap that SD-Access does not close by itself. Our guide to rolling out Cisco zero trust covers the staged approach, and our overview of Cisco zero trust services explains how the components fit. For a worked example of ISE in a regulated setting, see this engineering firm case study.

Do not remove the perimeter too early

NCSC is clear that deploying a given product does not equal a zero trust architecture. A frequent mistake is retiring legacy controls such as VPNs before the new segmentation and monitoring have been tuned. Run old and new controls in parallel, monitor in permissive mode first, and retire the old path only when logs show the new policy is behaving as intended.

Policy rollout: monitor, then enforce

A sound sequence for any site:

1. Onboard endpoints in open or monitor mode and record what authenticates.
2. Classify devices into groups and assign SGTs.
3. Build the policy matrix from observed flows, with explicit permits for required traffic and a default deny only once the flows are understood. Practitioners writing on microsegmentation in practice describe the same pattern: validated permit rules first, then restriction.
4. Move one building or floor at a time to enforcement.
5. Keep a documented rollback for each step.

Unmanaged and legacy devices need a plan: MAC-based onboarding, profiling in ISE, or a dedicated VN. Do not assume every device can authenticate with 802.1X.

DHCP, wireless and the details that cause late delays

DHCP

DHCP behaves differently in a fabric because the anycast gateway is on every edge node. Cisco’s DHCP session material notes that DHCP servers must accept and retain Option 82, and that relay agents use the source IP of the SVI for each IP pool. Check that your DHCP service meets those conditions during design, not during cutover.

Wireless

Fabric wireless ties access points to the fabric site and uses a dedicated controller. Radio design is still physical. Coverage, capacity and channel plans come from a survey, not from the fabric. A wireless survey before you size access layer density avoids paying for overlay features on top of poor radio conditions. For warehouses, our brief for warehouse wireless lists what to ask a supplier, and for halls of residence our note on student accommodation Wi-Fi covers timing.

IoT and AV equipment

Building systems, signage and AV endpoints often arrive late in a project and behave unpredictably. Checking that hardware from different vendors works together before it lands on the network saves effort, as this piece on AV hardware interoperability explains from the integrator’s side. Put these devices in their own VN with documented flows.

Connecting to the WAN

Fabric sites meet the wider network at the border. Decide how traffic leaves: through a transit, a firewall or an SD-WAN edge. Our Cisco SD-WAN design guide sets out the decisions to make before rollout, and the SD-WAN security checklist covers the controls around it.

Document the design: the HLD

A high-level design is not paperwork for its own sake. Cisco’s community template states that Cisco TAC may ask for an SDA HLD at any time to troubleshoot, and that escalation services require one. If you cannot produce a current document, support slows down.

Cisco also offers an SD-Access Design Tool, accessed with a Cisco.com login, which assesses your current Catalyst Center and ISE footprint, flags scale and latency concerns against the data sheet limits, and produces a requirements document and reference topology to feed the HLD. Use it as a cross-check, then add your own detail: IP plan, VN and SGT model, node placement, resilience, and operational runbooks.

A minimum HLD contains:

• Site list with fabric roles and hardware per site
• Underlay addressing and routing design
• VN, IP pool and SGT definitions with business rationale
• ISE node placement, policy sets and onboarding methods
• Wireless design and controller placement
• Border handoffs to WAN, data centre and internet
• Software versions and upgrade approach
• Monitoring, backup and change procedures

What benefits to expect, and what to treat with care

Cisco’s own figures, published in a 2019 regional blog, claim that SD-Access automation can cut provisioning time by 67%, improve troubleshooting efficiency by 80%, reduce the impact of security breaches by 48% and lower operating costs by 61% against traditional campus designs. These are vendor-reported internal figures, so use them as indicators of direction, not as a business case. Your own savings depend on how much of your current workload is manual, how clean the estate is, and how well policy is designed.

Sector considerations

• Education: large guest and student populations, high wireless density, safeguarding and filtering requirements. Separate VNs for staff, students, guests and building systems, with onboarding that does not rely on IT staff touching every device.
• Manufacturing: keep operational technology apart from corporate traffic, accept that some equipment will never support modern authentication, and plan maintenance windows around production. Our article on SD-WAN for manufacturing covers the connectivity side.
• Logistics and warehousing: roaming handheld devices, dense racking and several sites. Wireless design leads, with fabric segmentation protecting scanners and building systems.
• Hospitality and shared workspaces: many tenants or guests on shared infrastructure, where per-tenant VNs and consistent policy are the selling point.
• Property developers and housing associations: repeatable designs across many buildings, where templates and central management matter more than bespoke engineering.

For regulated environments, use VNs to create distinct, auditable segments rather than one flat network, and confirm requirements with your compliance lead. Our cybersecurity compliance basics guide is a useful starting point.

Our perspective

We have worked with Cisco infrastructure for more than 35 years, and our view on SD-Access is practical. The technology is sound, but the projects that go well are the ones where the design conversation starts with the business: which sites, which user groups, which risks, who will run it afterwards.

Three points we repeat to every customer:

• Audit before you architect. A short, evidence-based audit often changes the design, because the estate rarely matches the diagram.
• Design for the team that will operate it. A fabric that a small IT team cannot confidently troubleshoot is a poor design, however elegant. This is why many customers choose a managed or Network as a Service model for part or all of the run phase.
• Phase the policy. Connectivity first, visibility second, enforcement third. Rushing to enforcement is how outages happen.

SD-Access is not the right answer for every site. A small single-building network may be better served by a simpler cloud-managed design, and we will say so.

— Jacob

Where we can help

Re-Solution supports Cisco networks from first assessment to day-to-day operation. For SD-Access design that typically means a network audit to establish the baseline, professional services for design and deployment, and managed services or Network as a Service when you want us to run it. Pricing is scoped to each engagement. Contact us to discuss your sites.

FAQ

What is the difference between SD-Access and a traditional campus design?

A traditional campus is configured device by device, with VLANs and access lists tied to location. SD-Access uses a routed underlay, a virtual overlay and group-based policy managed centrally, so users keep the same policy wherever they connect. Cisco describes the fabric as supporting mobility, segmentation and programmability at scale.

How many fabric sites do I need?

It depends on geography, resilience and scale limits, not a fixed ratio. A site is defined by having its own border, control plane and edge nodes, so separate premises usually become separate sites joined by a transit. Check your proposed numbers against Catalyst Center and ISE limits before committing.

Does SD-Access give me zero trust?

Not on its own. It provides segmentation and policy enforcement, which are important building blocks, but NCSC guidance expects access decisions to use more than identity, including device and behavioural context. Treat SD-Access as one component of a wider zero trust design.

Can I migrate gradually?

Yes, and most organisations should. Build the fabric alongside the existing network, move one building or floor at a time, and keep legacy controls such as VPNs until the new policy is proven. Document each stage in the HLD.

Do I need an HLD if a partner builds it?

Yes. Cisco support can request a current HLD at any time, and escalation services require one. Make it a contract deliverable and keep it updated after each change.

Sources

• Cisco Software-Defined Access design guide
• NCSC: Zero Trust Network Access (ZTNA)
• Cisco Live BRKENS-2824: planning SD-Access deployment
• Cisco Community: Navigating DHCP processes in SD-Access
• Cisco Community: SDA High Level Design template
• Cisco Community: SD-Access Design Tool announcement
• Cisco Spain blog: network scalability for the digital era
• The Hardened Layer: microsegmentation in practice

Recommended

• Best Practices for Network Design Explained
• Network Infrastructure Planning Simplified
• Network assurance for IT teams: a practical guide
• How to connect to an IP network: enterprise guide for UK IT teams