The Network Intuitive put to the test

Back in January 2018 I wrote a blog post about the inroads I was making in discovering what the network intuitive is, and setting up Cisco Digital Network Architecture (DNA) Center and Software-Defined Access (SD-Access) for Cisco Live Europe in Barcelona. I also promised I’d come back with another blog post around what we plan on doing for Cisco Live US in Orlando, from a DevNet Zone infrastructure perspective. Fast forward almost half a year (time just flies when you’re having fun!) and here we are. Ready for Cisco Live US in Orlando with our second version of SDA. Let me tell you what has changed in the meantime.

In Barcelona, for our SDA fabric we were using DNA Center version 1.1, as you might remember if you’ve read my blog. For Orlando we will be using version 1.1.5. Although there were only four minor releases focused mainly on scalability and performance, the DNA Center team managed to include a couple of noteworthy features:
High availability is now supported as well as third-party virtual network function (VNF) software images from the likes of Fortinet, Palo Alto Networks, Riverbed and Check Point. And yes, you can use VNF software and hardware appliances from third party vendors with DNA Center.

While in Barcelona we used the Catalyst 3850s to build our fabric, in Orlando we moved to Catalyst 9300s as our edge devices and Catalyst 9500s for border and control plane. We’ve kept the ASR1002-HX as the router connecting the fabric to the outside world. We have also moved from our DNA Center virtual machine installation on a UCS B-series chassis to the DNA Center appliance. As a side note, the virtual machine version of DNA Center is no longer supported so you would need at least 1 DNA Center hardware appliance or ideally 3 for high availability for your own environment. Learn more about the Cisco DNA-Ready Infrastructure.

The upgrading process for DNA Center is much more streamlined these days. If you are not familiar with the upgrade process for DNA Center, I’ve gotta tell you, it’s quite the marvel. It is all cloud-based so you need to allow your DNA Center cluster outbound access to specific links on the Internet specified in the DNA Center release notes. Having the upgrades delivered over Internet makes it much faster and easier to get the latest fixes and features in your own environments.

I’m aware of the security conscious ones out there that say:”Oh no, not the cloud!” I’m also one of you actually, and I can tell you that as long as you allow only outbound access through your firewalls, to specific destinations, on specific ports I believe you should be fine. Make sure you also have those IPS/IDS signatures up to date, just in case!

Another major change is that you no longer need to know which specific application package has to be upgraded first. “Is it the automation one, and then which one from automation, the base or the SD Access one? Or maybe the application policy?” It’s all done automatically for you.

Personally I always choose to update to the latest version of the DNA Center applications. As soon as there’s an update available I install it and explore it. With DNA Center being a new product and the innovation pipeline for it booming, I’m really excited to see all the new features and fixes in play as soon as they are made available. I also have the luxury of having an appliance in a lab environment so yeah, there’s that too! You might want to test the new features in a test environment too before you go into production with the latest releases.

This brings us to another important point: DNA Center was built around a micro-services architecture with system functionality split into several different services or packages. Just to give you an example, the assurance functionality in DNA Center is split into several packages: base, path trace and sensor. Each one of these interacts and exchanges data with other DNA Center services to provide the assurance functionality.

Using a micro-services architecture brings all the usual advantages: first and foremost scalability. By splitting the platform into multiple services it is much easier to scale up or down. It also becomes much easier to develop new functionality in the platform. Just develop a new package and integrate it through APIs with the other packages. Parts of the platform can be developed in different programming languages in order to take advantage of either speed, parallel processing or just familiarity with a specific language on the development team.

We also integrated the wireless network into the fabric as we were planning. If you remember we didn’t want to overpromise and underdeliver. We have a Cisco WLC 5520 and 3802 APs as part of the fabric. This gives us seamless migration between wired and wireless for the same user. The security policy configured in DNA Center will follow the user throughout the network no matter how they connect to it: wired or wireless.

The last part that I wanted to cover are the APIs. In DNA Center version 1.1.5 the functionality exposed over the APIs is still in its infancy. What’s next for #CiscoDNA? For now, I can only say that you should definitely have a look at Adam Radford’s github repo.  It contains some great sample code and a Python library that will make it much easier for all of you to interact with the DNA Center API. You’ll also want to bookmark our learning labs!

I hope to see you all at Cisco Live this year in Orlando. The event will take place between June 10th and 14th. While there, please stop by the DevNet Zone and check out everything we have prepared for you.

I’m glad to say when building the DevNet Zone for Orlando we already started taking into consideration the feedback we got from you! Rest assured there will be more and as always please tell us what you think about all this and how we can make you more successful with everything you do day to day. Help us help you!