Preparing Campus Networks for SD-Access

Article

Preparing Campus Networks for SD-Access

Plan SD-Access in five practical steps, from inventory and identity policy to pilot validation and handover.

01

Make the current network and dependencies visible

Transformation starts with workflows, before a device list. Record the networks used by employees, printers, cameras and critical applications. Assign owners to IP pools, DHCP, DNS, NTP, identity services and external connections. Two devices sharing a VLAN do not necessarily need the same access. Compare inventory with observed traffic and record a successful baseline. This helps distinguish changes introduced by the pilot from problems that already existed.

02

Validate the underlay and fabric roles

Cisco SD-Access uses Catalyst Center for management, LISP for the control plane, VXLAN for the data plane and TrustSec for policy. Assess these responsibilities alongside hardware, software and licensing compatibility. Plan edge, border and control-plane roles for capacity and redundancy. Define tests for underlay reachability, MTU and external connectivity. Routing at the fabric boundary must account for data centre, internet and WAN services. A healthy device is insufficient evidence that the campus works: application flows need separate validation.

CISCO · Figure 29

Cisco SD-Access: small-site topology

Figure 29 of the Cisco design guide shows campus connectivity, the colocated border/control-plane pair, fabric edges and the wireless services block together.

Remainder of Campus NetworkEdge firewall AFirewall pair shown in the remainder of the campus in the source figure.Edge firewall BThe second firewall in the pair shown by the source.Catalyst CenterCampus management and automation component. This figure does not depict management sessions as cabling.ISE PAN / MnTISE administration and monitoring personas in the remainder of the campus.DHCP · DNS · ADShared services grouped together on the campus side in the original figure.Campus routingRouting node shown between the upper campus connection and the two BN/CP nodes.BN / CP ABorder and control-plane roles share one device; the source shows a crosslink to the other BN/CP.BN / CP BSecond colocated border/control-plane node with alternate physical paths to edges and the services block.Local ISE PANThe local ISE node connected to the services block is labelled ISE PAN in the source; its role has not been changed.WLCWireless controller linked to the services block by a Layer 2 port-channel in the reference design.Services blockSwitch-stack or StackWise Virtual services block; routed links to both BN/CP nodes and a Layer 2 WLC link are shown.Fabric edge AFabric edge linked to both BN/CP nodes and a wired client in the source.Fabric edge BFabric edge linked to both BN/CP nodes and the fabric access point.Fabric edge CFabric edge linked to both BN/CP nodes and the second wired client.Fabric APAP cabled to edge B. Wireless clients are shown with radio symbols in the source, not wired connections.Wired clientWired endpoint attached to fabric edge A in the source.Wired clientWired endpoint attached to fabric edge C in the source.Wireless clientWireless endpoint from the source; no physical cable has been added.Wireless clientSecond wireless endpoint from the source; no physical cable has been added.BN: Border node · CP: Control plane · AP: Access point · MnT: Monitoring
  • Routed link
  • Access / Layer 2 link
Explore the diagram

Select a node to read its role. Drag to pan or use the buttons to zoom.

Cisco's small-site physical reference model. BN and CP are colocated on two nodes; WLC and local ISE connect through the services block. No VN or SGT segments absent from the source have been added.

03

Tie policy to identity and application needs

Virtual networks organise logical separation while security groups organise permitted relationships. Design Cisco ISE authentication and authorisation with certificate infrastructure and device diversity in mind. Document exceptions for devices that cannot authenticate; broad access should not become a permanent workaround. Obtain required resources and ports from application owners. Test denied paths as well as permitted ones. Defined ownership and review dates turn segmentation into an operating practice rather than a one-time configuration.

04

Test coexistence through a bounded pilot

Limit the first scope to a representative but manageable user group or floor. Prepare acceptance scenarios for wired and wireless access, roaming, guests and critical applications. Define coexistence boundaries between legacy VLANs and the fabric; extend Layer 2 only where needed. Agree on decision makers and rollback thresholds before the change window. Test identity service and connectivity failures alongside successful flows. Evaluate device evidence, application tests and user feedback together.

05

Make operational handover part of the design

After a successful pilot, order migration waves by application criticality. Current topology, access matrices, rollback steps and alarm ownership belong in the handover. Operators should trace a user access issue through authentication, policy and the data path. Assign responsibility for access transfer, configuration backups and policy review. Plan post-change monitoring and acceptance decisions in advance. A discussion with Trustnet can clarify current network constraints, business priorities and a practical transition scope.

Technical sources

RELATED CONTENT

View all