Introduction to SD-Access

Enterprise networking can get pretty complex. There’s usually a campus, some remote branches, remote workers, and we connect everything together with WAN connections. We have many devices on the physical layer including routers, switches, firewalls, wireless LAN controllers, etc.

There is a lot going on in the logical topology: we have VLANs, VRFs, routing protocols, access-lists, firewall rules, etc. We configure pretty much everything manually with perhaps a bit of network automation to make our lives easier.

Back in 2007/2008, SDN showed up with the promise of automating everything and getting rid of the CLI by defining everything in software.

SDN however, is mostly about datacenters. In the data center, everything is about applications. In an enterprise, it’s about (mobile) users and devices. We have users working everywhere using laptops, tablets, and smartphones.

Enterprise networks use a lot of hardware appliances. New firewall? Order a Cisco ASA. Extra wireless LAN controller (WLC)? Order another WLC appliance.

Wouldn’t it be nice if we could spin up new services for our enterprise networks, similar to how cloud services work? If you need a new firewall, just click on a button and it starts a new vASA. Need another WLC? Hit the button, and it starts a virtual WLC.

This is one of the promises of Cisco’s SD-access: complete automation of your enterprise network, similar to how SDN/cloud solutions work. Here’s what it looks like:

There are five main components:

• Fabric
• DNA Center Appliance
• Identity Services Engine (ISE)
• Network Data Platform (NDP)
• DNA Center Dashboard

Fabric

Let’s start with the fabric. This is where you find all hardware components that you are familiar with: routers, switches, wireless LAN controllers, access points, etc. This includes devices that run IOS and IOS XE.

SD-access uses an underlay responsible for forwarding traffic; it’s only job is to provide a transport mechanism. We keep the underlay network simple. We use an overlay network for the different services. The overlay network is flexible and programmable. Why this separation?

You don’t see this separation on most campus enterprise networks but it makes sense. For example, if you want to support a new application on your network then perhaps you have to change an existing access-list. If you change this access-list then it could also affect other applications in your network. You might want to implement the access-list changes during maintenance hours. If you mess up, you can always do a rollback.

With an underlay and overlay network, changes to the overlay network won’t affect your underlay network. It’s similar to using tunneling protocols like GRE or DMVPN. You can mess around with the tunnels, but it won’t affect the underlying network.

We use APIs to configure the hardware devices and to launch new services. It’s still possible to use the CLI for troubleshooting.

The fabric consists of three key components:

• Control plane: based on Locator Identity Separator Protocol (LISP)
• Data plane: based on Virtual Extensibe LAN (VXLAN)
• Policy plane: based on Cisco TrustSec (CTS)

LISP simplifies routing by removing destination information from the routing table and moving it to a centralized mapping system It’s similar to DNS, a router sends a query to a central LISP mapping system and asks where a destination address is. This results in smaller routing tables and requires less CPU cycles.

We could use LISP on the data plane, but it can only tunnel L3 traffic. SD-access uses a modified version of VXLAN on the data plane, one of the reasons is that VXLAN supports L2 encapsulation.

On the policy plane we use Cisco TrustSec, Scalable Group Tags (SGT), and the SGT Exchange Protocol (SXP). We add endpoints that require a similar network policy to a shared group, and we add an SGT to the group. The SGT is a tag that is separate from a network address and you can attach network policies (QoS, PBR, etc.) to it.

This allows you to create network policies without mapping it to IP addresses or subnets. The SGT is added in the VXLAN header.

DNA Center Appliance

The DNA Center Appliance is Cisco’s SDN controller for enterprise networks and supports IOS/IOS XE devices.

DNA Center Dashboard

DNA center dashboard is the portal where you manage everything. It’s web-based, and right now only available as a hardware appliance. If you ask me, that’s strange considering SD-access is all about virtualization. They will probably release a virtual version sometime.

There are four key attributes of DNA center:

• Design
• Policy
• Provision
• Assurance

Design

This is where you design your entire network:

• Build the network hierarchy: add sites, buildings, etc.
• IP address management: add the network and subnet addresses you want to use for your networks.
• Network settings: configure DHCP, DNS, SNMP, and Syslog servers. You also create QoS and wireless profiles here.
• Image repository: manage all IOS/IOS XE images of your devices in one place.

Policy

This is where we configure everything that is related to network policies. You create the policies and DNA center translates your policies into configurations for the hardware devices in the fabric.

Provision

This is where we add new devices to the network and where we apply network policies to devices.

Assurance

Assurance is where you monitor the entire network. You can see an overview of all network devices, (wireless) clients, and applications. You can monitor the health status and an overview of all issues in the network.

ISE

ISE is Cisco’s AAA product and has been out for a while now. ISE applies the policies you create through DNA center.