- Posted by IPTel Solutions
- On June 4, 2019
- 0 Comments
One of the Cisco Digital Networking Architecture corner stone concepts is Software Defined Access (or simply, SD Access). It is challenging to describe what Cisco SD Access is, in just a few words, without it sounding like a marketing pitch. The message I have been receiving from Cisco is that SDA is the (only) way that we should be designing our future networks. To me that seemed like a bitter pill to swallow because one had to admit that the current practices were no longer valid, and failure to adopt this paradigm shift would result in certain doom.
This week, after attending Cisco Live in Melbourne, I had a breakthrough moment around the subject of SDA and why we should care about it. I would caveat this by saying that the world won’t end if we didn’t all adopt SDA – but there are real advantages to be had if we adopted this new way of thinking.
The adoption of CTS (Cisco TrustSec) over the last ten years has not been very far reaching. TrustSec is a framework that made Network Segmentation easier by assigning Tags to traffic, and to treat that traffic based on Source and Destination Tags, as opposed to Source and Destination IP addresses. This distinction is crucial, because IP addresses are hard to deal with and one user may appear in numerous IP Source Addresses, thus making ACL’s very complex. SGT (Scalable Group Tag) is the name given to these tags, and they can convey more than just Security (as their initial acronym of Security Group Tag suggested). Scalable means that the tag can be used for Security, QoS and many other uses. It’s also an IETF standard.
I would wager that one of the top reasons for the low acceptance of TrustSec in the market , is that customers don’t always have the right hardware in place to support TrustSec. Many years have gone by since Cisco announced TrustSec, and the discussion often centered around device compatibility to support inline tagging or SXP (SGT Exchange Protocol) support.
So, here is my SDA elevator pitch from an engineer’s perspective: SDA creates a network layer over the top of your existing network to allow the easy distribution of SGT’s. The more correct terminology is that SDA is an overlay technology that sits on your underlay (your existing network). Remember what I said about SGT not being supported on many devices? SDA solves that problem because SGT’s no longer get involved in the underlay. Problem solved. The overlay however still needs to deal with SGT’s and this is done by fewer, and more strategic devices in the network. The overlay is also referred to as the Fabric.
The fabric has another benefit over and above a regular design that may already be using SGT’s – and this is the inclusion of Virtual Networks. VN’s are in essence the same thing as VRF’s (Virtual Routing and Forwarding) that we know from MPLS and VRF-Lite in the Enterprise. VRF’s have been used for a long time to logically separate parts of the network that need to be kept separate. But if you have ever tried to stitch together an Enterprise campus using VRF-Lite, you’ll know the pain that was involved there – it was not trivial. Now, imagine a VN for Students, Staff and Guests – users in each VN are isolated from each other and need to be explicitly allowed to inter communicate. Okay, but what are SGT’s used for then? SGT’s are the Micro-segmentation lever in SDA. They allow us to further sub-divide the class of endpoints in a VN. For example the Biomedical VN might contain sensors, pumps and temperature probes – each type can be assigned its own SGT.
So – let me re-iterate the point of SDA in a more technical level. In a word, it’s VXLAN. SDA allows the transportation of VN and SGT information through the network through the VXLAN header in the IP frame. The IP frame travels through your WAN, LAN, or multi-vendor network (unaware of all of this). That in essence is the power of SDA. It’s an Overlay technology that enables a lot of cool features.
In SDA we interface with the fabric in two places
Fabric Edge – clients/APs connect here
Fabric Border – exit point to the DC or WAN.
One of the most important pieces of SDA is the Controller. This is not to be confused with an SDN controller that constructs the individual IP flows, but rather, the SDA controller is a Cisco device that maintains the IP Address to SGT/VN mappings in a database and the uses the LISP protocol. The Controller can be deployed in various sizes and of course in High Availability. If the Controller Function were to fail entirely, then it would not stop user traffic from flowing, but it would prevent new LISP communications from being established.
SDA is a real thing and it is finding its way into customer networks. It’s probably the most significant development from Cisco since the advent of MPLS almost 20 years ago. It’s interesting to note that Cisco also invented Tag Switching 20 years ago, which later became standardised as MPLS Label Switching and was widely adopted. SDA relies on standards based protocols like LISP, IS-IS and VXLAN. It can sound like an acronym soup at times, but the more you immerse yourself in this topic, the clearer it will be.