Understanding Cisco Software-Defined Access: Key Constructs & Considerations.

What is Cisco Software Defined Access?

Often referred to as SD-Access or simply SDA, this technology represents a significant evolution in enterprise networking, offering a robust solution that enhances network visibility, security, and management efficiency. Utilising the principles of software-defined networking (SDN), SDA automates network configuration and policy enforcement to provide seamless and secure connectivity. Key benefits of Cisco SDA are simplified network management through automation, consistent security policies across the network, faster service delivery, and the ability to adapt quickly to changing business needs. By abstracting network complexities, SDA empowers IT teams to focus on strategic initiatives rather than routine network tasks.

Key constructs of Cisco SDA

An evolution of the Local Area Network (LAN) from traditional Layer 2 and 3 architectures we have seen in the past, there are two important constructs to understand in the context of Cisco SDA, both playing important roles in illustrating the advantages it provides over legacy networking technologies. Built on Software Defined Networking (SDN) using a Fabric architecture, Cisco SDA is becoming prevalent in enterprise networks now as organisations look to transition to better visibility and troubleshooting enablement, greater efficiency and management through automation and orchestration, and greatly enhanced security postures. Let’s look at each of these in more detail. 

Software Defined Networking –

This is not a new concept, dating back to the mid 2000’s with SDN controllers maturing around the late 2010’s and becoming prevalent (in the campus LAN) from the release of Cisco’s DNA Centre (DNAC) in 2017. SDN’s purpose is:

1. To remove the control plane functionality from the networking device so that policy can be controlled and enforced from a central point on the network (the SDN controller). This ensures all network devices are consistent in the way they process (control) policies in forwarding traffic across the data plane.  

2. To remove the management plane functionality from each individual network switch allowing the SDN controller to push configurations centrally with consistency in an automated manner. Whilst we have had network management platforms do this for many years through template pushes and batching of CLI commands, this still requires legacy connectivity to a network device’s management plane to apply a configuration (as processed across its individual control plane). SDN does this in a much more efficient manner by taking ownership of the management and control plane functions off the individual devices leveraging the latest API-based protocol mechanisms to accomplish these tasks.  The added benefit of decoupling the network’s management plane from the device is the ability to write advanced automations and orchestration workflows to the controller directly without the need for connecting to each individual device as traditional network management platforms are reliant on. 

Cisco’s SDN controller for the enterprise network is called Catalyst Centre (previously known as DNA Centre) and most Cisco Networks have, or are, transitioning to this from legacy network management systems (NMS) such as Cisco’s legacy Prime Infrastructure or third-party platforms such as SolarWinds. The advantages in SDN controller functionality, even without an SDA implementation, is significant with enhanced automation and visibility (Assurance) over traditional network management monitoring capabilities. When integrated into an SDA network however, the benefits really stack up.

Fabric Architecture –

A network fabric is used by the SDN controller to automate and orchestrate an “underlay” network which is then built on with an “overlay” logical network designed for enhanced network segmentation based on organisational needs. The underlay is handled automatically by the controller and significantly simplifies the network design requirements of traditional networks where layer 2 and layer 3 topologies were dependencies. With a fabric, there is no longer a layer 2 consideration, so complex spanning tree and trunking protocol designs are a thing of the past! What is important to understand here though, is the purpose of the fabric in facilitating access aligned to a Zero Trust policy where the network becomes the enforcement point for what is allowed to talk to each other and what isn’t. Where traditional networks rely on VLAN segmentation and Access Control Lists, the SDA fabric builds network connections on the fly for all hosts based on their identity and associated access policies through the defining of Scalable Group Tags (SGT’s).

The important construct to note here is that the SDA fabric allows for 2 discreet policy enforcement models;

1. Micro segmentation - where network endpoints are grouped into like-minded groups contained within a Virtual Network (VN), construct and policies determine what can and can’t communicate with devices within the VN through the mapping of device and/or user identities to SGTs. Within a VN, the network fabric itself is the enforcement point.

2. Macro segmentation - where endpoints within a Virtual Network need to communicate with devices in another Virtual Network. This gets accomplished via traditional firewall-based policy enforcement allowing for granular control.

Ideally, there is a balance to strike between the number of Virtual Networks and defined groups within them, when designing a fabric. Trade-offs exist between micro and macro segmentation designs. Basing segmentation around macro segmentation means you have more of a dependency on firewall rules and less of a dependency on SGT’s and vice versa. Consideration needs to be given in defining group categories, their connectivity and interaction requirements in balancing macro and micro segmentation policy needs.