Controller-based SDN architecture
Baha Abu-Shaqra, PhD (DTI uOttawa)
Network Engineering (career change)
This post explains controller-based, software defined architecture (overlay, underlay, and fabric). Further, this post compares traditional campus device management with Cisco DNA Center enabled device management.
This post covers topics 6.3 Describe controller-based, software defined architecture (overlay, underlay, and fabric) and 6.4 Compare traditional campus device management with Cisco DNA Center enabled device management (Section 6.0 Automation and Programmability) of the CCNA exam topics list.
You may also be interested in Automation and programmability.
Before we dive in, I try to make the world a little better. You're invited to read my letter to uOttawa President?Jacques Frémont about how to easily implement policy reforms to prevent supervisor bullying of uOttawa students: uOttawa President Jacques Frémont ignores university bullying problem. You may also be interested in How to end supervisor bullying at uOttawa.
SDN / SDN system architecture - introduction
An SDN controller centralizes control plane functions such as calculating the best path for traffic to flow through the network, based on a variety of factors such as load balancing and security policies. Network devices share information with the controller, which uses this information to calculate routes for the entire network.
The degree of control plane centralization in an SDN network varies depending on the specific solution that is implemented. SDN controllers can centralize all or part of the control plane, leaving some functions on the individual network devices.
NBIs allow external apps to interact programmatically with the controller using scripts and applications. SBIs allow the controller to interact programmatically with the network devices using scripts and applications. NBIs and SBIs rely on APIs to define the methods for communication.
An API specifies how different software components can interact. It defines the functions, objects, protocols, and other building blocks that an application can use to access features or data provided by another application or system. In the context of SDN, NBIs and SBIs use APIs to establish a well-defined way for external applications and network devices to communicate with the SDN controller.
Cisco Software-Defined Access (SD-Access)
Cisco Software-Defined Access is Cisco’s SDN solution for automating campus LANs, e.g., office wired and wireless LANs. Cisco’s ACI (Application Centric Infrastructure) is Cisco’s SDN solution for automating data center networks. SD-WAN is Cisco’s SDN solution for automating WANs.
Cisco DNA (Digital Network Architecture) is the controller at the center of SD-Access. The following diagram illustrates the basic SD-Access architecture.
The DNA Center is in the control layer. Under it are the network devices in the campus LAN in the infrastructure layer. These devices form the fabric of SD-Access. Above the DNA Center in the application layer are scripts and apps that interact with DNA Center.
*Fabric
Fabric refers to the combination of the underlay and overlay, the physical and virtual network as a whole. The underlay and overlay are both necessary to make SD-Access work.
The underlay is the underlying physical network of devices and connections which provide IP connectivity, for example with a routing protocol such as IS-IS. The underlay is basically a network of interconnected multilayer switches. The underlay network is typically optimized for low latency and high performance.
The overlay is the virtual network built on top of the physical underlay network. SD-Access uses a protocol called VXLAN (virtual extensible LAN) to build tunnels. Hosts in the LAN communicate with each other through VXLAN tunnels between two switches.
*SD-Access underlay
There are three different roles for switches in SD-Access:
1) Edge nodes, these are switches that connect to end hosts, like a traditional access layer switch;
2) border nodes, these connect to devices outside of the SD-Access domain, for example connecting to a WAN router; and
3) control nodes, these use a protocol called LISP (Locator ID Separation Protocol) to perform various control plane functions.
In a brownfield deployment, you can add SD-Access on top of an existing network if your network hardware and software supports it. You can Google “Cisco SD-Access compatibility matrix” to know about which hardware supports SD-Access.
In a greenfield deployment, a totally new network is built for the purpose of SD-Access. In this case, the DNA Center configures the devices for the optimal SD-access underlay. For example, all switches are L3 and use IS-IS as their routing protocol. All links between switches are routed ports, so STP is not needed to avoid L2 loops. And a FHRP is not needed either. And edge nodes (access layer switches) act as the default gateway of end hosts. This is known as a routed access layer. L3 is all the way down at the access switches which end hosts connect to.
In a traditional LAN, STP is used to prevent L2 loops and a FHRP (e.g., HSRP) is used by the distribution layer switches to provide a redundant default gateway for the end hosts. End hosts send traffic out of their local networks to the virtual IP provided by the FHRP, 192.168.1.1.
However, in an SD-Access underlay all connections between switches are L3, and IS-IS is used to exchange routing information. STP and an FHRP are not needed. Instead, the access layer switches are the default gateways of the end hosts.
*SD-Access overlay
LISP provides the control plane of SD-Access. LISP maintains a list of mappings between EIDs (endpoint identifiers) and RLOCs (routing locators). EIDs identify end hosts connected to edge switches, and RLOCs identify the edge switch which can be used to reach the end host. LISP uses these mappings to route traffic between end devices.
LISP differs from the traditional control plane. A DNS-like system of mappings is used to locate destination hosts instead of a traditional routing table.
VXLAN provides the data plane of SD-Access, the tunnels used to actually forward traffic in the data plane. How VXLAN tunnels work with LISP: SW3 is a control node. SW2 tells the control node that PC2 is reachable via SW2. So SW3 creates that mapping.
PC1 wants to send traffic to PC2, so PC1 sends the traffic to the default gateway SW1. SW1 asks SW3, how can I reach PC2? SW3 informs SW1 that PC2 is reachable via SW2. The message from PC1 is forwarded over a VXLAN tunnel between SW1 and SW2.
Cisco DNA Center management platform
Cisco DNA Center is a software-based network management and automation platform that helps organizations simplify, automate, and secure their networks.
领英推荐
Cisco DNA Center is a cloud-based platform that provides a single pane of glass for managing all aspects of the network, including devices, applications, and users. It also includes a number of features that help to automate network operations, such as: device provisioning and configuration, network assurance, security policy enforcement, and network analytics.
DNA Center is an SDN controller in SD-Access architecture, but it can also be used as a general network management tool even in networks that do not use SD-Access. DNA Center has two main roles. First, it is the SDN controller used in SD-Access. Second, it can be a network manager in a traditional network that is not using SD-Access. In this case, it acts as a central point to monitor, analyze, and configure the network.
DNA Center is a software application installed on Cisco UCS server hardware. DNA Center has a REST API which can be used to interact with the server hardware. DNA Center’s SBI supports protocols such as NETCONF and RESTCONF, as well as traditional protocols such as Telnet, SSH, and SNMP to control and monitor devices.
DNA Center enables "intent-based networking" (IBN), which allows the network engineer to communicate their intent for network behavior to DNA Center, and then DNA Center handles the actual configurations and implementing policies on the devices.
DNA Center allows the engineer to specify the intent of the policy, such as which groups of users can access which servers, and DNA Center will take care of the exact details of implementing the policy.
This is what configuring policies on DNA Center looks like.
To look at DNA Center you can check out the DevNet sandbox at https://developer.cisco.com/site/sandbox/
Cisco DNA Center (DNAC) network management vs traditional network management
Traditional network management key characteristics
DNA Center-based network management key characteristics
Other posts in this automation and programability series
Key references
Bard, Google AI. "Controller-based SDN architecture" (and several follow-up questions). Bard, Google AI, 2023-11-12. Accessed 2023-11-12.
Hussain, M., Shah, N., Amin, R., Alshamrani, S. S., Alotaibi, A., & Raza, S. M. (2022). Software-defined networking: Categories, analysis, and future directions. Sensors, 22(15), 5551.