SD-Access Overview

Why your organisation needs Software Defined Access

At the time of starting this blog (early February 2018) most network engineers around the World haven’t even heard about Software Defined Access. Although in few years time everybody will embrace this new technology, at the moment it is very new and cutting edge. When you look at LinkedIn you can still see many engineers getting excited about the new way of re-sequencing access list. They are debating about advantages of Layer 3 versus traditional Layer 2 access network. Legacy networking that we have been embracing for the past 20 years is burnt into engineer’s DNA.

When we approach the Enterprise network design we need to figure out the following:

IP Addressing Scheme
Core & Distribution Layers vs Collapsed Core approach
VLAN numbering for Data, Voice and Access Points
Any requirement to stretch VLANs between various locations
Network Policy and Access Lists
Wireless Design for both Corporate and Guest Users
Routing Protocol and Spanning Tree Flavours
Layer 2 or Layer 3 edge design
WAN edge design

That isn’t even a comprehensive list but those challenges need to be solved. The requirements often lead to a solution that either doesn’t scale or is hard to manage. It also has a number of adhoc exceptions or tweaks. Even if highly skilled engineers design and implement the solution, it requires ongoing maintenance and support. Whenever you need to deploy a new service you need to get back to the drawing board and again – figure out IP address, VLANs, policy, etc. Troubleshooting large enterprise LAN can pose a significant challenge and expanding it often requires multiple teams to agree on the requirements mentioned in the list above.

Software Defined Access solves many traditional LAN drawbacks

SD-Access or simply SDA is essentially what Cisco calls intent-based networking solution. It translates business requirements into the network design and provides actionable insights. Both wired and wireless networks share a single fabric. This means that user experience is independent of access technology. Software Defined Access addresses the following challenges:

Network Deployment – Implementation Complexity and Wireless Integration
Service Deployment – Segmentation, Policy and On-boarding
Network Operations – Troubleshooting

The concept of a Network Fabric splits the underlying network architecture from overlay virtual layer where users and services reside. The terms “underlay” and “overlay” are the most important to understand in Software Defined Access architecture. I will explain them in more detail in subsequent sections. In summary SD-Access provides the following network characteristics:

IP Addressing doesn’t have direct association with service anymore
Policy Enforcement uses Endpoint Group instead of IP address
VLAN ID has no relevance and isn’t configurable
Single IP subnet can be shared between multiple access areas while maintaining full layer 3 segmentation
Full user mobility between different access areas is possible without changing endpoint network address

How can we achieve all this? SDA basically turns the traditional networking concept on its head. Lets explain legacy LAN design, security and operations in more details before showing the huge benefits of Software Defined Access.

Challenges with traditional campus LAN

Upgrading the core network so far was a fairly complicated project. We have described the typical approach in this blog few years ago. The benefits from the upgrade were usually greater throughput and resilience at the network layer. The main business benefit was effectively extra capacity underpinned by the same design principle.

The typical Campus Network is built around VLANs and IP addressing. In vast majority of cases and according to the best practices, a single VLAN would map to a single subnet. We can then associate this subnet with a security group. Lets look at some specifics around the standard enterprise LAN and its drawbacks.

Options for Layer 3 boundary in a typical network design

Layer 2 access with the IP gateway at Distribution or Core Layer. This design requires trunking VLANs to the access switches and often sharing them between different areas. It leads to large layer 2 domain with spanning tree blocking redundant ports. That design can be improved if the upstream switches can form a cluster eliminating logical loops and STP blocking. The nature of trunking VLANs upstream makes it impossible to standardize certain VLAN IDs for data, voice if they use different IP subnets. Adding new subnet requires defining new VLAN ID and trunking this new VLAN to the relevant edge switches.
Layer 3 access with the IP gateway terminated at the Access layer. This design is much better and allows standard switch configuration with identical VLAN IDs for voice, data, wireless and different IP subnets. It scales much better than the previous option and avoids large layer 2 domains with potential loops or blocking ports. It also provides the ability to summarize routing information and isolate failure domains much better. The only problem with this design is that some old devices often need to be on the same subnet to communicate which is impossible across layer 3 boundary. Next options solves layer 2 adjacency problems without complete network redesign.
Hybrid access with most VLANs terminated at the access layer but extending some special VLANs upstream. In this design the trunk between access and distribution/core layer would carry a single point-to-point VLAN to build routing adjacency as well as any VLANs that require stretching to the other access areas. This design could be a temporary stage between Layer 2 and Layer 3 access. It allows certain level of standardization while accommodating any legacy devices that may require adjacency at layer 2.

Policy enforcement and security in a traditional LAN

From the security perspective all those designs are linking VLANs and IP subnets to a particular security group i.e. data, voice, wireless, application or database servers. Whenever you need to deploy a new service you need to plan its network details. You also need to work with multiple teams to provide network reachability. Once you get the basic end-to-end IP routing for the new service, you are modifying your access policies, change access lists, firewall rules. All this is to make sure it meets your organisation security policy. User mobility also becomes complicated because in many cases endpoint IP address would change when moving to a different part of the network.

Network operations and management

Any live network requires management, monitoring and day to day support. The operation teams not only have to deal with incidents but often with deploying changes to add new services. If your organisation requires 24/7 support, your team would typically be dealing with urgent tickets and contacting end users in the day. The night shift executes any network changes, add new VLANs, create IP subnets, pre-configure end user ports, add firewall rules and many other deployment or maintenance tasks.

Legacy network design is not fit for purpose

When you think about the business requirements in today’s World it becomes obvious that traditional LAN becomes a bottleneck. It simply doesn’t offer enough flexibility and often limits what an organisation can achieve. Network deployment and operations becomes a major challenge. Adding any new service requires huge effort and work between many teams. IP addressing scheme and VLAN IDs are the main focus of attention. Finally your business security policy is very difficult to consistently manage.

In a nutshell SDA solution is a programmable network architecture which provides policy based connectivity to the network applications. The network is implemented via Cisco Digital Network Architecture also called DNA Center and described in more details in DNA Automation blog. All design aspects, segmentation and monitoring are centrally managed via DNA Center. It includes Network Assurance part which provides rich set of analytics. The key layer of SDA solution is SD-Access Fabric which provides both physical and logical network forwarding infrastructure. The concept of fabric allows splitting logical aspect of the solution from the physical forwarding plane. It breaks the association of service or application from VLAN or IP address.

Network Underlay connects routers, switches, access points and wireless LAN controllers

This layer is simply a physical infrastructure to provide IP forwarding capability. In SD-Access design there are no end user policies associated with this part of the network fabric. Its role is to provide end to end connectivity but the policies for applications and services are defined in a new virtual layer. The other way of looking at the network underlay is calling it a “black box” comprised of switches, routers and wireless lan controllers. All components establish IP connectivity with each other. The underlay is a Layer 3 network where recommended routing protocol is IS-IS. It isn’t used for any end user traffic directly so there is no need for Spanning Tree, VTP, HSRP or any other Gateway Redundancy Protocol. The network underlay design remains fairly static. DNA Center provides the ability to add more hardware capacity to it.

Network Overlay connects users, devices and applications based on defined policy

The new virtual layer that allows complete separation of end user policies from IP forwarding plane. This revolutionary approach has dramatic impact on deployment and operations. Any changes to the company policy only impact the overlay. The overlay has at least 3 main building blocks:

Data Plane – encapsulating packets with additional Virtual Extensible LAN (VXLAN) header
Control Plane – resolving users and devices to the VXLAN tunnel endpoint is done with Locator/ID Separation Protocol (LISP)
Policy Plane – translating business intent into a network policy with Scalable Group Tags (SGTs) and group-based policies

The next paragraph will delve into some more specifics that will show the difference between the traditional network and SD-Access packet forwarding.

Control Plane and Data Plane fundamentals in SD-Access

It is not our intention to provide full low level details of SDA operation in this blog. We just want to explain how it differs from the well known LAN design. In order to simplify things lets just assume that the security policy is fully open. We first want to understand how two endpoints communicate with each other via the network overlay. In the end of the day all endpoints still have the same IP stack. They all still require IP address, subnet mask, default gateway and DNS settings. It doesn’t matter if those are provided statically or dynamically. What we are trying to look at is the simplified packet walk through the fabric allowing bidirectional traffic flow.

Software Defined Access fabric components and terminology

The following are fabric control and data plane building blocks that must exist in every SDA environment:

Control Plane Node – acting as a central database tracking all users and devices when they attach to the network. It allows other components of the fabric (routers, switches and wireless LAN controllers) to determine the location of each endpoint.
Intermediate Node – pure IP forwarding device that connects edge nodes and provide Layer 3 underlay.
Edge Node – responsible for connecting endpoints and encapsulating/decapsulating endpoint traffic as it enters or leaves the fabric. It is also a policy enforcement point in the network.
Border Node – provides connectivity between traditional Layer 3 networks and the fabric.

In most SDA solutions there would be more parts including: Fabric WLC, Fabric APs and Extended Node. Those additional building blocks aren’t required for the simplified example that we explain here.

Sending endpoint traffic across the fabric

Let’s use the next example to explain both Control and Data Plane operation in SD-Access. It includes all basic components as well as two endpoints that are attached to two different edge nodes. The sequence of events is as follows:

Switch A and Switch B are Fabric Edge Nodes where the endpoints are attached
Switch C is physically connecting Switches A and B acting as Fabric Intermediate Node
Host A and Host B come online
Both Switch A and Switch B register MAC addresses and IP addresses of Host A and B with the Control Node
Host A needs to send an IP Packet to Host B
Switch A queries the Control Node and finds out that Host B is connected to Switch B
Switch A encapsulates original Endpoint traffic adding additional VXLAN header
The source IP address of the traffic is Switch A Loopback while the destination IP is Switch B Loopback
The packet travels through the underlay between both switches
Switch B acts as VXLAN tunnel endpoint and decapsulates the traffic as well as forwards it to Host B

This example also shows the difference between underlay and overlay. Any intermediate nodes that are sitting in the underlay don’t need to know any endpoint addresses. All they have to do is forward the traffic between tunnel endpoints (loopbacks). It also shows that you can have two hosts on the same IP subnet connected to different edge nodes. This is because edge nodes are querying the control node during ARP mechanism and it doesn’t matter what the host IPs are. If the source and destination belong to the same subnet there is no flooding or VLAN trunking. All traffic simply gets and additional VXLAN header and flows through the underlay until it hits the final edge node.

Enforcing Policy in SD-Access

The previous example showed the traffic flow between two endpoints in the most simplistic way. In reality there is one more crucial aspect of any network design that needs enforcing – the security policy. We have provided more details in policy enforcement article but essentially there are few parts to it:

Defining the security policy and pushing to the fabric from DNA Center
Enforcing policy in the data plane based on VXLAN headers and VRFs

The ability to disconnect the policy from endpoint IP addressing is the fundamental benefit of any SD-Access deployment.

Further documentation about Software Defined Access

At EDNX we have deep understanding and experience with both traditional networking and SDA. We have led on complex network migrations and upgrades in various industries where any outage shouldn’t exceed few seconds. In this article we have only touched the surface of what SDA is capable of. Our architects can give you a lot more insight for both wired, wireless and policy part of the solution.

If you are looking for a lot more detailed information about SDA technology online please check some of the resources listed below. They provide a lot more insight into various aspects of design and implementation of Software Defined Solution.

Digital Network Architecture Design Guide

Intent Based Networking

Software Defined Access on Techwise TV

There is also plenty of great videos on Cisco Live Website where you can find both introductory and Deep Dive sessions explaining the technology.