Welcome to Jeremy’s IT Lab. This is a free, complete course for the CCNA. If you like these videos, please subscribe to follow along with the series. Also, please like and leave a comment, and share the video to help spread this free series of videos. Thanks for your help. In this video we will look at software-defined networking. In the first video of this network automation series we already covered the fundamentals such as centralizing the control plane in an SDN controller, northbound and southbound APIs, etc. So, in this video we’ll take a more in-depth look at one of Cisco’s SDN offerings, SD-Access, Software-Defined Access. We’ll cover exam topics 6.3 and 6.4. You’ll learn new terms like overlay, underlay, and fabric which are essential concepts in SDN that we haven’t covered yet. Here’s what we’ll cover in this video. First I’ll briefly review the points about SDN that you’ll need to remember for this video. Then I’ll introduce Cisco’s SD-Access, including important concepts like underlay, overlay, and fabric. I’ll also introduce Cisco’s DNA Center management platform, which is an essential part of SD-Access, and compare it to traditional network management. Make sure to watch until the end of the video for a bonus practice question from Boson Software’s ExSim, the best practice exams for the CCNA. Let’s reviews some points about SDN. SDN is an approach to networking that centralizes the control plane into an application called a controller. Traditional control planes use a distributed architecture, which means that every network device has its own control plane. The control planes of each network device use protocols like OSPF to communicate with each other and share routing information, each device has its own ACLs and security rules, etc. That’s a distributed control plane. An SDN controller centralizes control plane functions like calculating routes. Network devices no longer use OSPF to share information with each other, instead they share information with the controller, which takes that information and calculates routes for the entire network. Now, depending on the SDN solution the entire control plane might be centralized in the SDN controller, or perhaps only part of the control plane is centralized, leaving some functions on the individual network devices. The controller can interact programmatically with the network devices using APIs. Specifically it uses what we call the southbound interface to do that. Then there is also the northbound interface, which is what allows us to interact with the controller using our scripts and applications. Okay, those are the fundamental points of SDN that I wanted to review. And here’s one more look at the SDN architecture we covered in the first video of this automation section. The applications are on top, the controller in the middle, and the network devices on the bottom. Actually, these three ‘layers’ of the architecture have names. On top there is the application layer. This layer contains scripts and applications that tell the SDN controller what network behaviors are desired. Note that this isn’t the application layer of the OSI model, this is a totally different concept. We’re not talking about the OSI model here. Anyway, next is the control layer. This contains the SDN controller that receives and processes instructions from the application layer. Although this is a separate concept from the ‘control plane’, this layer is also what contains the centralized control plane of the network. And finally there is the infrastructure layer, which contains the actual devices that are responsible for forwarding messages across the network. I didn’t mention these layers in earlier videos, so take the time to learn them now. The application layer contains apps and scripts for instructing the SDN controller, the control layer contains the SDN controller, and the infrastructure layer contains the network devices. Okay, so I’ve told you the basics of what SDN is and its purpose, but we still haven’t looked at a specific example of SDN. So, let’s take a look at one, Cisco Software-Defined Access. Cisco SD-Access is Cisco’s SDN solution for automating campus LANs. So, office wired and wireless LANs, for example. Cisco has other SDN solutions, for example ACI, Application Centric Infrastructure, is their SDN solution for automating data center networks. Remember when I explained spine-leaf architecture earlier in the course? That is used extensively in ACI data center networks. Cisco also has SD-WAN, their SDN solution for automating WANs. But for now let’s look at SD-Access. Cisco DNA, Digital Network Architecture, Center is the controller at the center of SD-Access. In the previous video about REST APIs we sent a REST API call to DNA Center, so perhaps you remember that name. Okay, let’s look at the basic SD-Access architecture. At the center, in the control layer, we have DNA Center. And then under it we have the network devices in our campus LAN in the infrastructure layer. These devices form the fabric of SD-Access, and I’ll explain that term in the next slide. In the application layer we have our scripts and apps that interact with DNA center. These could be tools we develop, third-party tools, or tools directly from Cisco. DNA Center itself also has a GUI that we can use to control it. Okay, so that’s the basic architecture of Cisco’s SD Access. Notice how it fits perfectly into the SDN Application layer, Control layer, Infrastructure layer model. Next let’s look at that term ‘fabric’. To understand the fabric, you need to understand two other terms. First, the underlay is the underlying physical network of devices and connections, wired and wireless, which provide IP connectivity, for example with a routing protocol like IS-IS. Usually I’d use OSPF as an example, since it’s the most common interior gateway routing protocol, but soon you’ll see why I chose IS-IS for this example. Basically the underlay is a bunch of multilayer switches and their connections. Then the overlay is the virtual network built on top of the physical underlay network. For example, SD-Access uses a protocol called VXLAN, virtual extensible LAN, to build tunnels. And fabric is the term we use to refer to the combination of the overlay and underlay, the physical and virtual network as a whole. For example, this is the underlay network. The physical multilayer switches and their connections form the underlay, and they are perhaps running IS-IS to share routing information and provide connectivity throughout the network. Then the overlay network consists of VXLAN tunnels, for example between these two switches. When hosts in the LAN communicate with each other, their traffic is sent over the VXLAN tunnels. That’s the overlay network. And the fabric refers to the physical and virtual network as a whole, overlay plus underlay. Both are necessary to make SD-Access work. Okay, now let me give a little more detail about both the underlay and overlay. So, let’s talk about the underlay. The underlay’s purpose is to support the VXLAN tunnels of the overlay. To make a virtual network of tunnels, the devices first need to be connected and able to reach other of course, so the underlay is very important. There are three different roles for switches in SD-Access. Those are edge node, these are switches that connect to end hosts, like a traditional access layer switch. Then there are border nodes, which connect to devices outside of the SD-Access domain, for example connecting to a WAN router. And finally there are control nodes, which use a protocol called LISP, Locator ID Separation Protocol, to perform various control plane functions. I think LISP is far beyond what you need to know for the CCNA, so just know that it is used for the control plane of SD-Access. Note that you can add SD-Access on top of an existing network if your network hardware and software supports it. This is called a brownfield deployment, when you add it on to an already existing network. If you’re curious which hardware supports it, you can google ‘Cisco SD-Access compatibility matrix’, but you don’t have to know the specific devices for the CCNA. And also note that in this case DNA center won’t configure the underlay, because this could be a major risk to the current working production network. Ideally you will be using a greenfield deployment, which is a totally new network built for the purpose of SD-Access. In this case DNA center will configure the devices for the optimal SD-access underlay. For example, all switches are layer 3 and use IS-IS as their routing protocol. That’s why I mentioned IS-IS in the example earlier. Additionally all links between switches are routed ports, so STP is not needed to avoid Layer 2 loops. And edge nodes, so access switches, act as the default gateway of end hosts. This is known as a routed access layer, we’ve brought layer 3 all the way down to the access switches that end hosts connect to. Let me demonstrate with a diagram. Here’s a traditional LAN. Notice that STP is used to avoid layer 2 loops, and an FHRP, for example HSRP, is used by the distribution layer switches to provide a redundant default gateway for the end hosts. So, to send traffic out of their local network, they will send it to the virtual IP provided by the FHRP, 192.168.1.1. In an SD-access underlay, however, all connections between switches are Layer 3 and IS-IS is used to exchange routing information. Note that STP is no longer needed, and an FHRP isn’t needed either. Instead, the access layer switches are the default gateways of the end hosts. Now we have a routed access layer. Now let me briefly introduce a few aspects of the SD-Access overlay. First, LISP provides the control plane of SD-Access. A list of mappings of EIDs to RLOCs is kept. Let me explain those terms. EIDs, endpoint identifiers, identify end hosts connected to edge switches, and RLOCs, routing locators, identify the edge switch which can be used to reach the end host. Of course, there is a lot more detail to cover about LISP, but I think with just that you can see how it differs from the traditional control plane. Instead of a traditional routing table to locate destination hosts, a DNS-like system of mappings is used. Cisco TrustSec, CTS, provides policy control such as QoS and security policy. Just remember that name, Cisco TrustSec, you don’t have to know about its functionality. And finally VXLAN provides the data plane of SD-Access, the tunnels that are used to actually forward traffic in the data plane. Let’s look at how VXLAN tunnels work with LISP. Notice that SW3 is a control node, so it is important for the function of LISP. PC2 is connected to SW2, and it tells the control node that PC2 is reachable via SW2. So, SW3 creates that mapping. Now PC1 wants to send traffic to PC2, so it sends it to the default gateway, SW1. SW1 asks SW3, how can I reach PC2? And SW3 informs it that PC2 is reachable via SW2. So, the message from PC1 is forwarded over a VXLAN tunnel between SW1 and SW2. Okay, that’s all I’ll say about the overlay for now. VXLAN does more than just create tunnels, it provides a lot of features to SD-Access which I won’t get into in this video. Just know the difference between fabric, overlay, and underlay, and know some basics of SD-Access like edge node, border node, and control node, LISP, VXLAN, and Cisco TrustSec. Now let’s look a bit more at DNA Center. DNA Center itself has two main roles. First, it is the SDN controller used in SD-Access, as I mentioned earlier. Additionally it can be a network manager in a traditional network that isn’t using SD-Access. In that case, although it doesn’t provide SD-Access functions, it still acts as a central point to monitor, analyze, and configure the network. Although I will mention both purposes, for this lecture we’re focusing on the SD-Access application. Note that DNA Center is a software application installed on Cisco UCS server hardware. I mentioned Cisco UCS in the virtualization lecture of this course. DNA Center has a REST API, as you already know, which can be used to interact with it. And its southbound interface supports protocols such as NETCONF and RESTCONF, as well as traditional protocols Telnet, SSH, and SNMP to control and monitor devices. DNA Center enables something called intent-based networking, IBN, yet another buzzword. Basically, the goal is to allow the engineer to communicate their intent for network behavior to DNA Center, and then DNA Center will take care of the details of the actual configurations and policies on the devices. It simplifies the process, and allows engineers to spend time on more important things than analyzing and configuring policies on devices one at a time. Here’s one example. Traditional security policies using ACLs can become very cumbersome. For example, ACLs can have thousands of entries, and the intent of entries is easily forgotten with time and as engineers leave and new engineers take over. Looking at another engineer’s configurations and trying to figure out the intent is often not an easy task. And configuring and applying ACLs correctly across a network is cumbersome and leaves room for error. DNA Center, on the other hand, allows the engineer to specify the intent of the policy, for example this group of users can’t communicate with this group, or this group can access this server but not that server, etc, and DNA Center will take care of the exact details of implementing the policy. This is what configuring policies on DNA Center looks like. Notice on the left here we have source groups. Of course, you’d have to define the groups first, which users belong in which groups. And here we have those same groups as destination. Up here we have the legend for the colors in the policy grid. Note that the entire grid is white now, so default. However, let’s say any traffic sourced from users in the developers group and destined for the Test_Servers group should be permitted. Now, what about traffic sourced from the guest group? They shouldn’t be able to access our servers, so we’ll make that red. How about users in the employees group? Maybe that depends on various factors, we can’t just permit or deny all traffic, so we would want to make a custom policy for that. We can go ahead and define policies like this, it’s a very simple and straightforward way of creating and applying policies across the entire SD-Access fabric. No need to configure policies on devices one at a time. I’m not showing the whole process here of course, but one thing to note is that the engineer can write an explanation for each policy made, making it much easier to understand the purpose of policies later. Okay, now let’s take a look at some of the other features of DNA Center. In the menu on the left side you can see there are various sections, and I’ve opened the design section. Here we can build the network hierarchy, manage IP addresses and subnets, configure DHCP servers, DNS servers, etc, among other things. Here, for example, I’m looking at one site, SJC-20, on a map. You can map your enterprise’s sites all over the world and create hierarchies based on country, etc. In the policy menu you can configure policies like the example I showed you earlier. You tell DNA Center how the network devices should behave, and DNA Center will change that into configurations on the devices in the network. For example, here’s that group-based access control page again. A simple and logical way to configure network policies. In the provision menu we can manage our device inventory and add new devices. Other services are available as well, as you can see in the menu. Here’s the inventory page. In the side bar you can see that there are 3 unassigned devices under global. By default, when you add devices to DNA Center they will be under the global site, until you assign them to a specific site. You can see their status of ‘managed’ here, this means they are under control of DNA Center, they are not independent devices. This is also the default setting when you register a device in DNA Center. Here you can see the compliance status of the devices. The top device is compliant with our policies, but the bottom two aren’t. I clicked on one of the non-compliant devices, and you can see why it is labeled as non-compliant. The software image, the version of IOS, is not up to date. The version should be 17.03.03, but currently it is 16.11.1c. We can use DNA Center to update that later if we want. And here you can see that it is also non-compliant with some security advisories. Anyway moving on, in the assurance section of the menu you can monitor the status of the network. You can make sure the devices are all up and running without issues. For example, here I can see which devices in the network are considered ‘healthy’ by DNA Center. 3 of 4 devices are in good health, and 1 of them simply has no health data. Okay, that’s all we’ll look at for now, but if you want to look around DNA Center yourself you can check out the DevNet sandbox at sandboxdnac.cisco.com, and you can see the username and password here. I highly recommend checking it out and looking around at what DNA Center has to offer. Okay, that was a quick look at DNA Center, but to be honest you don’t have to be familiar with all of the functions of DNA Center for the CCNA. Basically, just understand its role as a network controller in SD-Access architecture, and also understand that it can be a network management platform in a traditional network. However, the exam topics do state that you should be able to compare DNA Center-enabled device management with traditional device management. Actually, I’ve covered most of these points already when I first introduced network automation, but let’s review to make sure. First, let’s review some characteristics of traditional network management. Devices are configured one-by-one via SSH or console connection. This is what we’ve been doing throughout the labs in this course. Devices are manually configured via console connection before being deployed. This means when deploying a new device to a network. You first have to manually set it up before connecting it to the network. Configurations and policies are managed per-device, in a distributed manner. There is no central management. New network deployments take a long time due to the manual labor required. Setting up dozens of new devices manually takes a lot of time, and also errors and failures are more likely due to increased manual effort. Now, I don’t want to make it seem like traditional network management is bad, but you should be aware of these potential downsides. Now some characteristics of DNA Center-based network management. Devices are centrally managed and monitored from the DNA Center GUI or other applications using its REST API. In this video I showed you the DNA Center GUI, but using the REST API other applications can be used to interact with DNA Center too. With DNA Center, the administrator communicates their intended network behavior to DNA Center, which changes those intentions into configurations on the managed network devices. Configurations and policies are centrally managed, they’re all stored and managed on DNA Center. Software versions are also centrally managed. DNA Center can monitor cloud servers for new versions and then update the managed devices when needed. In this video you saw an example of DNA Center showing us an alert for a device with an old software version. Finally, with DNA Center new network deployments are much quicker. New devices can automatically receive their configurations from DNA Center without manual configuration. Not only is this faster, human error is reduced too, which is a huge bonus. Okay, that’s all I’ll say about this. Most of these points we have already covered, but make sure you’re aware of them because it is mentioned on the exam topics. Okay, let’s review what we covered. We first reviewed SDN, and I newly introduced the terms application layer, control layer, and infrastructure layer. Then, as an example of SDN, I introduced some concepts of Cisco SD-Access. The main takeaways from this section are the concepts of underlay, overlay, and fabric. Make sure you understand those concepts. Then I showed you some functions of Cisco DNA Center, and compared network management with DNA Center to traditional network management. Remember, 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 don’t use SD-Access. Make sure to watch until the end of the quiz for a bonus practice question from Boson Software’s ExSim, the best practice exams for the CCNA. Okay, let’s go to quiz question 1. Which of the following terms describes the network of devices and physical connections? Pause the video now to select the best answer. Okay, the answer is A, underlay. The underlay refers to the underlying physical network, and then the virtual overlay network is built on top of it. The combination of underlay and overlay is called the fabric. Okay, let’s go to question 2. In which of the following layers would you expect to find scripts that interact with the controller? Pause the video now to select the best answer. Okay, the answer is B, application. In SDN architecture, the application layer includes apps and scripts that can be used to interact with the controller, which is in the control layer. Finally the bottom layer is the infrastructure layer, which includes the network devices. Okay, let’s go to question 3. Which of the following is a characteristic of an optimal SD-Access underlay network as configured by DNA-Center? Pause the video now to select the best answer. Okay, the answer is B, all links between switches are layer 3. This means that spanning tree is not needed, and no links will have to be disabled because there is no risk of layer 2 loops. Okay, let’s go to question 4. Which protocol is used to create virtual tunnels in the SD-Access overlay? Pause the video now to select the best answer. Okay, the answer is D, VXLAN. It is used to create virtual tunnels in the overlay network. And although we didn’t cover any details at all, the ‘extensible’ in the name ‘virtual extensible LAN’ is very important. It means that VXLAN supports many different features which are used by SD-Access. Okay, let’s go to question 5. Which of the following are valid switch roles in Cisco SD-Access? (select three) Pause the video now to select the best answers. Okay, the answers areA, C, and D. Control, border, and edge nodes. These are the three different switch roles in Cisco SD-Access, and there is no such thing as a management node. Okay, that’s all for the quiz. Now let’s take a look at a bonus question in Boson Software’s ExSim for CCNA.