Not every network should be a fabric. SD-Access is a genuinely powerful architecture, but it is also a big commitment - a controller, an identity service, compatible hardware, and a operational model your team has to learn. The most valuable thing a senior engineer can do with SD-Access is know when not to deploy it. This article is the honest design conversation the vendor slide decks skip.
It closes the SD-Access series. For the mechanics, see the earlier articles; this one is about judgement. For the wider context, see the network virtualization pillar.
What SD-Access is genuinely good at
Give the architecture its due - where it fits, it fits well:
- Large campuses with a strong segmentation requirement. If you need to separate guests, IoT, corporate, and contractors consistently across thousands of ports and enforce it by identity, SD-Access does this better than any pile of VLANs and ACLs. This is its home turf.
- Environments where users and devices move. The anycast gateway and LISP roaming mean policy follows people between buildings without re-configuration. For a hospital, a university, a large corporate campus, this is real value.
- Organisations that already run ISE and want to extend identity-based policy into the network fabric itself. If you have made the TrustSec investment, SD-Access is the natural extension.
- Greenfield builds at scale where you can design the underlay, choose compatible hardware, and adopt the operational model from day one - rather than retrofitting.
Where a fabric does not fit
And now the part the design guides underplay:
The honest cost of a fabric
Every SD-Access deployment carries costs that are easy to underweight in the planning phase and impossible to ignore once you are live:
- The controller is a dependency. Catalyst Center provisions and operates the fabric. It needs to be sized, made redundant, backed up, patched, and understood. It is another critical system, and when it has a problem, your ability to change the network has a problem.
- Troubleshooting is different, and initially harder. "Why can't this host reach that host" now involves LISP map-caches, VXLAN encapsulation, SGT policy, and the controller's view - not just a routing table and a MAC table. The skills transfer, but there is a learning curve, and it lands during outages.
- You are more locked in. A fabric is a Cisco architecture end to end. That is fine if it is a deliberate choice, but it is a choice, and it narrows your options.
- The underlay still has to be right. All the fabric magic sits on an IGP with correct MTU and fast convergence. Get the boring part wrong and the clever part fails in confusing ways.
The alternatives SD-Access competes with
SD-Access is not the only way to get segmentation and identity-based policy:
The middle option is the one most under-considered: traditional access plus TrustSec gives you identity-based segmentation - the main reason to want SD-Access - without the controller, the LISP, or the hardware refresh. For an organisation whose real requirement is "segment by identity" rather than "automate the campus", it is often the better fit. And it is built on the real TrustSec technology PingLabz has captured standalone.
The decision framework
Ask these five questions, in order:
- Do you have a real, funded segmentation requirement? If no, most of the reason for SD-Access is gone - stop here and consider a traditional design.
- Is it a large campus with mobility? If yes, SD-Access's strengths align. If it is a handful of small sites, they do not.
- Is the hardware compatible, or is a refresh funded? If not, the business case has to justify a forklift.
- Does the team have the skills, or a plan and appetite to build them? A fabric run by a team that resents it is a liability.
- Have you considered traditional + TrustSec as the middle path? If your real need is segmentation, this may deliver it with far less change.
If you answer yes to the first four and have genuinely weighed the fifth, SD-Access is a strong choice and its complexity is buying you something real. If you are reaching for it because it is new, or because a vendor slide was compelling, pause. The best network is the one that meets the requirement with the least complexity your team can operate well - and sometimes that is a fabric, and sometimes it very much is not.
Key takeaways
- SD-Access fits large campuses with a real segmentation requirement, user mobility, an existing ISE investment, and compatible hardware. There it is genuinely strong.
- It is a poor fit for small sites, networks with no segmentation need, incompatible hardware, teams without the skills, and simple stable networks that already work.
- The honest costs: the controller is a critical dependency, troubleshooting is different and initially harder, you are more locked in, and the underlay still has to be right.
- The most under-considered alternative is traditional access + TrustSec - identity-based segmentation without the full fabric, on real technology.
- Decide with a framework: real segmentation need → scale and mobility → hardware → team readiness → whether traditional+TrustSec is the better middle path.
- The best network meets the requirement with the least complexity the team can operate well. Sometimes that is a fabric; often it is not - and knowing the difference is the expert skill.
That closes the SD-Access series - an honest concept-and-components treatment of the 12.5% of the CCIE EI blueprint that cannot be labbed without Catalyst Center, grounded throughout in the real LISP, VXLAN, and TrustSec technology PingLabz has captured standalone. The full cluster index lives on the network virtualization pillar.
