Cisco SD-Access Lab: Part 2

Cisco DNA SD-Access "Software Defined-Access" is the future of Cisco enterprise networks. 

This is the second part in a two part series, to provide you insight in to how you can quickly get your Cisco SD-Access Lab up and running.

SD Access Lab Recap

In part 1 of this series we looked at the background of Software Defined Networking , and how this is translated in the Cisco SDA Fabric world.

Cisco DNA Center is a fundamental component, along with the key pre-requisites of Planning, Cisco ISE integration, software compatibility and Licensing.

Let's pick this blog up where we left off from the last one - with SD-Access Policies.

ASSOCIATED BLOG: 

• Cisco SD-Access Lab Part 1
• Cisco SD-Access Deployment
• Cisco DNA Center Enablement

Policies

Next, we'll need to define the policies that will dictate the network intent.

All access control, macro and micro segmentation and QoS policies are created in the Policy section.

SGTs are created here and are nested within Virtual Networks, which DNAC will deploy during provisioning.

We can use Group-Based Access Control to define the policies that ISE will enforce with TrustSec Security Group Tagging (known in the DNAC world as Scalable Group Tagging).

The image blow shows the definition of the group based access control:

When our device team has finished installing and patching all our switches together, we're ready for discovery and provisioning using LAN Automation!

In our lab, we manually discovered our fusion router and configured it with an IP address on the port facing the border router.

This means the fusion can be used as a seed for discovering every device in our SD-Access network.

When we ran the LAN Automation, our switches were in a factory default mode, meaning they have a PnP agent running as if they were straight out of the box.

Setting our fusion router as a seed device caused DNA Center to push some temporary config to the router in order to provide connectivity to all the downstream devices.

Once LAN automation has discovered and claimed all the devices, we stopped the process which caused DNAC to remove all the temporary config from the seed device.

With minimal configuration effort, we've got a fully interconnected LAN, also known as our underlay! 

This vanilla install is now ready for the full underlay and overlay to be provisioned.

ASSOCIATED BLOG:

• Cisco DNA Center Beginners Guide
• Zero Trust Architecture (ZTA) Introduction
• Zero Trust Architecture (ZTA) Deployment

Provisioning Underlay

Once we have created our network underlay with LAN Automation, (which has created a layer 3 IS-IS domain), we can take the step to "provision" our underlay.

This is where the config from our previous design work is pushed to the network (think AAA, Syslog, QoS etc).

Then we began to construct our fabric overlay, which is where SD-Access really comes to life.

ASSOCIATED BLOG:

• Cisco DNA Spaces Introduction
• Cisco AI Analytics in operation
• Cisco Machine Learning and AI

Fabric Overlay

We define our device roles, which for us were all on one device as we had a Fabric-in-a-Box.

Even if we had 100 switches, it would all take just a matter of minutes to define and deploy all of these devices to the fabric overlay.

When onboarding our device to the fabric overlay, DNA Center automatically deploys an enormous amount of complex config, mostly comprising of LISP and VXLAN.

These are the vital components of the fabric overlay, making up the control and data planes.