Nobody builds a greenfield campus. You have an existing network with real users, real applications, and real uptime requirements, and any move to SD-Access has to happen alongside it, not instead of it overnight. The interesting engineering in SD-Access adoption is rarely the fabric itself; it is the boundary where the fabric meets everything that is not yet fabric.
This article covers how SD-Access interoperates with a traditional campus and the realistic migration paths. It extends the SD-Access architecture article and the Network Virtualization cluster guide.
Everything Happens at the Border
The fabric is a bubble. Inside it, traffic is VXLAN-encapsulated, endpoints are tracked by LISP, and policy is enforced by group tags. Outside it, the world is ordinary IP: the WAN, the data centre, the internet, and the parts of the campus you have not migrated yet. The Border Node is the airlock between the two, and it does the translation.
There are two flavours of border, and the distinction matters:
The border is where the fabric's internal constructs (VNs, SGTs, LISP mappings) get translated into things the outside understands (VRFs, prefixes, ordinary routing). Getting this translation right, especially preserving segmentation across the boundary, is the hard part of any SD-Access design.
Carrying Segmentation Across the Boundary
Inside the fabric you have macro-segmentation (Virtual Networks) and micro-segmentation (SGTs). The moment traffic leaves the fabric, those constructs do not exist unless you deliberately carry them onward. Two mechanisms:
- VRF-Lite hand-off at the border. Each fabric Virtual Network maps to a VRF, and the border extends those VRFs to the next-hop device using VRF-Lite (subinterfaces or 802.1Q per VN). This preserves macro-segmentation into the non-fabric network. It is the same VRF construct from the routing cluster, doing the same job at the fabric edge.
- SGT propagation (inline or SXP). To preserve micro-segmentation, the group tag must travel with the traffic. Inline SGT carries it in the frame to TrustSec-capable next hops; SXP (SGT Exchange Protocol) carries IP-to-SGT bindings out-of-band to devices that cannot do inline tagging. Without one of these, group policy stops at the border.
The common mistake is building a beautiful segmented fabric and then dumping everything into a single VRF at the border, collapsing all that separation the moment traffic leaves. If segmentation matters inside the fabric, it has to be carried across the border deliberately.
Migration Strategies
You do not flip a campus to fabric overnight. The realistic approaches:
The parallel approach is what most organisations use: stand up the fabric, connect it to the legacy network through the border, and move users across in waves. During the transition, a user on the fabric and a user still on the legacy network reach each other through the border, which routes between the fabric VNs and the legacy VLANs. As migration completes, the legacy footprint shrinks until it is gone or reduced to a few non-fabric-capable devices behind the border.
What Does Not Move Cleanly
Honesty about the friction points, because they drive real project timelines:
- Non-fabric-capable hardware. SD-Access needs Catalyst 9000-class switches at the fabric edge. Older access switches cannot be fabric edges; they either get replaced or sit behind the border as a legacy island.
- Multicast and legacy protocols. Applications that assume a flat Layer 2 domain, certain multicast designs, or non-IP protocols need careful handling across the fabric boundary. Test them explicitly.
- IP addressing assumptions. The fabric's anycast-gateway and host-mobility model changes how addressing behaves. Applications hard-coded to specific gateway MACs or subnet layouts can surprise you.
- The operational shift. The biggest migration cost is often not technical. Teams used to CLI must learn to operate through Catalyst Center, and the troubleshooting model changes. Budget for the learning curve.
FAQ
Can SD-Access and a traditional network coexist?
Yes, and they almost always must during migration. The Border Node is the interconnection point, routing between fabric Virtual Networks and the legacy network.
How do I keep segmentation when traffic leaves the fabric?
Map each Virtual Network to a VRF and extend it with VRF-Lite at the border for macro-segmentation, and propagate SGTs (inline or via SXP) for micro-segmentation. Otherwise segmentation collapses at the boundary.
Do I have to replace all my switches?
The fabric edge needs capable hardware (Catalyst 9000). Non-capable switches can remain behind the border as a legacy segment, but they cannot be fabric edges. This drives the hardware refresh side of most projects.
What is the safest migration path?
Parallel: build the fabric alongside the existing network, bridge at the border, and migrate users in waves. Avoid big-bang cutovers.
Can a small branch use SD-Access?
Yes, via Fabric-in-a-Box, which collapses the fabric roles onto one or two switches so a small site joins the same policy model without a full fabric.
Key Takeaways
- SD-Access adoption is dominated by the border: where the fabric meets the WAN, data centre, internet, and un-migrated campus.
- The Border Node translates fabric constructs (VNs, SGTs, LISP) into ordinary routing (VRFs, prefixes) for the outside world.
- Preserve segmentation across the boundary with VRF-Lite (macro) and SGT propagation (micro), or it collapses the moment traffic leaves.
- Migrate in parallel: build alongside, bridge at the border, move users in waves. Layer 2 hand-off and Fabric-in-a-Box are transitional tools.
- Friction points: non-fabric-capable hardware, legacy L2/multicast assumptions, addressing dependencies, and the CLI-to-controller operational shift.
Next: choosing the right segmentation layer, or the Network Virtualization cluster guide.
