It was interesting in 2017 watching the Enterprise Mobility space reacting to how software defined architectures and automation have become increasingly prevalent across several technology domains. This SD architecture and automation first made it to Cisco’s enterprise mobility with APIC-EM – a controller that can provision and configure your network devices in just a matter of clicks. Now with DNA Centre and SD-Access knocking at our door, perhaps it’s worth a delve into what SD-Access is, the problems it’s trying to solve and what the future holds. I’m an engineer at heart, so I’ll try to focus on the important stuff.

What is SD-Access?

SD-Access is a new architecture that allows intelligent segmentation of network traffic. Network operations can apply a common policy – whether the user is on wired and wireless – and have that policy follow users, regardless of their location in the network. Sounds just like Converged Access? Well we know how well that turned out! But stick with me.

The SD-Access solution creates an overlay, also referred to as the fabric on top of a traditional campus LAN. The fabric overlay runs on top of the physical hardware, which is now referred to as the underlay. By having this fabric overlay, an administrator can easily segment and apply a common policy to the network through centralised orchestration without having to reconfigure each individual network device. This makes life easier because often we had separate policies for wired and wireless users but now we can have one.

The really great thing about SDA though is that it doesn’t matter what your topology looks like! Of course, there are some best practices which I highly recommend you adhere to, and yes, brownfield deployments can be a bit trickier, however, in principle, if you have IP connectivity and have both your fabric edge nodes and fabric border nodes talking to each other, the fabric builds itself. It uses VxLAN encapsulation and the IS-IS routing protocol but any similarity with Cisco’s ACI (if you know about that), pretty much ends there. There’s no CLOS network architecture here, and this is the campus LAN not the data centre.

SD-Access components

What’s in an SD-Access network? Perhaps there is another similarity with ACI here, as most of the components are the same as you would buy for any LAN or WLAN project. SDA is primarily formed of following components:

  1. ISE – The Identity Services Engine is the policy engine that drives device onboarding and maintains security in the network through use of security group tags.
  2. Fabric Edge Node – The fabric edge node is where your users, devices and APs connect at the access layer.
  3. Intermediate Node – The intermediate nodes sit between the fabric edge and border nodes providing simple layer 3 connectivity between the fabric nodes.
  4. Fabric Border Node – The fabric border node sits in with the core, and acts as the path out of the fabric to an external network. It also acts as the control plane for endpoint mapping.
  5. Fabric Wireless LAN Controller – The fabric WLC joins wired/wireless mediums into a common fabric and provides updates on client roaming, mac addresses and locations in the fabric.
  6. DNA Centre – DNA Centre is the central management platform where all monitoring, configuration, analytics and policy application are performed. This is actually the one device that is solely required for SDA.

At this point hopefully you can see SDA is an overlay fabric that runs on physical hardware – the underlay. If so great! If not then just for a minute consider your traditional unified wireless network with either LWAPP or CAPWAP (depending on how long you’ve been in the industry). When a wireless packet travels from the AP it’s encapsulated with the CAPWAP header and when it reaches the WLAN controller the encapsulation is removed and off the packet goes to it’s desired destination. Replace the word ‘CAPWAP’ with ‘VxLAN’ and there you have it! We’ve been using an ‘overlay’ type architecture for years and many people just haven’t realised it.

The problem SD-Access is trying to solve

So that’s what SDA looks like. The obvious next question is ‘Why?’! Really the answer is that the way we are doing this now may be the way we are used to, but it is slow and inefficient!

Our traditional campus networks are built using networking components that are engrained in our brains. I’m talking about spanning trees, VLANs, Access Control Lists, Port Security – to name just a few. If you think about it in a world driven by technology, this is quite static and cumbersome. As your network grows or new sites are built, it takes time to roll out those additional networks and there’s a heavy reliance on IP.

With SD-Access the importance of IP is drastically reduced. In this new world security policies are assigned – by the ISE in the way of a tag – and follow users wherever they are in the virtual network!  It is a dynamic approach that is built for users and devices, not for IT administrators. But the result is that is it not just more secure, it gives those IT managers more time to run and maintain the networks. And speaking of network maintenance, the all new DNA centre can extract detail from Netflow, Application Visibility Control, RADIUS logs and Location to provide that bigger picture. Over time DNA Centre not only forms a baseline for your network, allowing you to almost predict a potential problem, but also converts data into actionable intelligence. This is an incredibly handy feature for those of us who have experience working as TAC engineers.

Future of SD-Access

Having covered a bunch of stuff at Cisco Live, having read documents online as well as the recently published validated design guide, I am genuinely excited by the concept of SDA. I think it’s going to make our lives easier. For example, the impact of the WannaCry ransomware attack back in May last year could have been drastically reduced with SD-Access, with the ability to isolate the issue before it spread. We see it time and time again; with frugal IT budgets, lack of standardisation or documentation, network outages can vary from hours to days – and beyond in some cases. This is where I believe WhiteSpider – with probably as great an expertise as anyone in the Software Defined space – offers genuine value in helping organisations achieve that standardisation be it, locally, regionally or globally. Check out some of our case studies to see how we’re different and what expertise we bring to the sector.

Bonus Tip – with Cisco’s recent acquisition of Viptela and their SD-WAN offering, it’s only a matter of time before we see SD-Access included in SD-WAN offerings. That is all from me for now, please keep an eye out for future blogs around migration scenarios, or if you’d like to see a more under the hood style blog please reach out to us.