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’ll look at network automation. Actually this will be a series of videos covering various topics related to network automation, and this first video will be an introduction to some of the foundational concepts which we will cover in more detail in later videos. Automation is section 6.0 of the CCNA exam topics, and it is 10% of the exam. Read these exam topics carefully. They state that you have to be able to explain, compare, describe, recognize, and interpret different things. However you don’t actually have to be able to automate networking tasks yourself. Cisco just wants you to understand various topics related to network automation, but the actual hands-on automation is left for other certifications at the CCNP level and above, as well as the DevNet certification track. In this video we’ll mostly be looking at these three topics, 6.1, 6.2, and 6.3, giving a general overview of network automation and its benefits. Here’s what we’ll cover. First I’ll give a quick overview of why network automation is used, and some of its benefits. I’ll then explain the logical planes of network functions, the data plane, control plane, and management plane. Maybe you’ve heard of these before, but maybe you haven’t. I’ll explain what they are, because they are essential to understanding the next topic, software-defined networking. While introducing SDN, I’ll also introduce APIs and data serialization. As I said, this video will be an introduction to all of these topics, and then I’ll cover them in greater detail in the next few videos. And make sure to watch until the end of the video for a bonus practice question from Boson Software’s ExSim for CCNA, the best practice exams for the CCNA. So let’s look at network automation. Previous versions of the CCNA focused on the traditional model of managing and controlling networks. Actually, the current version does too, but you are expected to have a basic understanding of various topics related to network automation, and that’s what we’ll focus on in these next few videos. In the traditional model, engineers manage devices one at a time by connecting to their CLI via SSH. Telnet connections are possible too of course, as well as connections to the console port. Some devices support a GUI also. But the main point here is that devices are managed and configured one by one. So, let’s say your company wants to add a loopback interface to all of their routers. You connect to R1 using SSH, configure the loopback interface, save the config, and exit out. Then you do it for R2. And R3. And R4. And every one of the hundreds of routers in your company network. So what are some downsides to managing a network like this? Here are a few. First, typos and other small mistakes are common. I’m sure that as you’ve been doing practice labs for the CCNA you’ve made typos at some point. Sometimes you realize it immediately and fix it, but then other times it can take a lot of time troubleshooting to find that the problem was just a typo in an IP address, for example. It is also time consuming and can be very inefficient especially in large-scale networks. Repetitive tasks can be automated and performed in a fraction of the time. And here’s another issue that might be harder to imagine if you don’t have any work experience as a network engineer yet. It is difficult to ensure that all devices adhere to the organization’s standard configurations. An organization will usually have standard configuration templates that they use for their devices, and it’s important to ensure that these policies are upheld throughout the network. However, as individual network engineers make individual changes over the years, the configurations can start to drift away from the standard. This can cause issues down the line, for example making troubleshooting more difficult because the devices don’t all have similar configurations. Of course, when I talk about the disadvantages of the traditional model, I’m talking about it in comparison to network management and operation using automation. Network automation offers many key benefits. Here are some of them. First, human error is reduced, for example typos. Instead of a network engineer directly logging in to the CLI and manually entering commands, the task can be automated. Networks become much more scalable. New network deployments, network-wide changes, as well as troubleshooting can be implemented in a fraction of the time. Also, network-wide policy compliance can be assured, for example making sure all devices have the proper standard configurations, all devices have the correct software versions, etc. And the improved efficiency of network operations reduces the opex, meaning operating expenses, of the network. Each task requires fewer man-hours, and engineers can focus on more important things. For example, in the same situation as before when we need to add a new loopback interface to hundreds of routers, instead of logging into each router one by one and manually configuring a loopback interface, which could take hours of time, a python script could perform the task and make the proper configurations in a fraction of the time. Note that there are various tools and methods that can be used to automate tasks in the network. Here are some examples. SDN, Ansible, Puppet, Python scripts, and many more. Throughout these videos I’ll introduce multiple different methods, but for the rest of this video let’s focus on the concept of SDN, software-defined networking. To understand SDN, you have to understand the logical planes of network functions. Let me explain. Here you can see two simple questions. What does a router do? And what does a switch do? Here are some example answers. A router forwards messages between networks by examining information in the Layer 3 header. And a switch forwards messages within a LAN by examining information in the Layer 2 header. Okay, but is that all that routers and switches do? A router also uses a routing protocol like OSPF to share routing information with others routers and build a routing table. It also uses ARP to build an ARP table, mapping IP addresses to MAC addresses. For example, it would use ARP to learn the MAC address of the next hop router when forwarding a packet. It also uses Syslog to keep logs of events that occur. We are also able to use SSH to connect to a router and manage it. And of course there are many more things that routers do, as we’ve learned in this course. How about switches? A switch uses STP to ensure that there are no Layer 2 loops in the network. It builds a MAC address table by examining the source MAC address of frames. Like a router, it also uses protocols like Syslog and SSH. Those are just some examples, there are many more functions of a switch. And if it’s a Layer 3 switch, it can have the same functions of a router, like using OSPF to build a routing table. Anyway, the point is that routers and switches do a lot of different things. They don’t just forward messages at Layer 2 or Layer 3. And these various functions of network devices can be logically divided up, logically categorized, into what we call planes. Typically we divide the functions into three planes. The data plane, the control plane, and the management plane. Let’s take a look at the functions of each plane. First let’s look at the data plane. All tasks involved in forwarding user data from one interface to another are part of the data plane. So, this is what you usually think of a router or switch doing, forwarding messages. A router receives a message, looks for the most specific matching route in its routing table, and forwards it out of the appropriate interface to the next hop. Or to the destination, if its directly connected. It also de-encapsulates the original Layer 2 header, and re-encapsulates with a new header destined for the next hop’s MAC address. All of these functions are part of the data plane. Likewise, a switch receives a message, looks at the destination MAC address, and forwards it out of the appropriate interface. Or it floods it out of all interfaces when appropriate. This also includes functions like adding or removing dot1q VLAN tags. Also, functions like NAT, which changes the source and/or destination addresses before forwarding, is part of the data plane. It’s part of the process of forwarding a message. Also, deciding to forward or discard a message due to ACLs, port security, etc is part of the data plane. Note that another name for the data plane is the forwarding plane, because that’s what it does. It forwards messages. Here’s an example with two routers. R1 receives a packet, and the data plane processes the packet to forward it out of another interface to R2. And then R2’s data plane processes the packet to forward it out of another interface. In this instance R2 discarded a packet from R1. Perhaps an ACL configured on R2’s interface caused it to make that decision. Anyway, that’s an action of the data plane. Next, let’s look at the control plane. How does a device’s data plane make its forwarding decisions? How can a router choose which interface to forward a packet out of? How does it know what the next hop is? Devices use things like their routing table, MAC address table, ARP table, STP, among other things, to make these forwarding decisions. Functions that build these tables, and other functions that influence the data plane, are part of the control plane. So, the control plane controls what the data plane does, for example by building the router’s routing table. The functions of the control plane are considered overhead work. Let me explain that statement with some examples. The OSPF protocol itself doesn’t forward user data packets, but it informs the data plane about how packets should be forwarded. Likewise, STP itself isn’t directly involved in the process of forwarding frames, but it informs the data plane about which interfaces should and shouldn’t be used to forward frames. One more example, ARP messages aren’t user data, but they are used to build an ARP table which is used in the process of forwarding data. So, I think you can get an idea of what is involved in the control plane. Let me demonstrate again with a diagram. R1 and R2 communicate using OSPF, and this allows both of them to build their routing tables. These routing tables control the actions of the data plane, which is where the actual forwarding of data packets takes place. So, in traditional networking the data plane and control plane are both distributed. Each device has its own data plane and its own control plane, so they are distributed throughout the network. It’s not one centralized control plane that controls the entire network. This is different than in software-defined networking, which we’ll look at shortly. Finally let’s look at the management plane. Like the control plane, the management plane performs overhead work. However, the management plane doesn’t directly affect the forwarding of messages in the data plane. Instead, it consists of protocols that are used to manage devices. For example, SSH and Telnet, which are used to connect to the CLI of a device to configure and manage it. Or Syslog, which is used to keep logs of events that occur on the device. Also SNMP, which is mainly used to monitor the operations and status of the device. NTP is another example, which is used to maintain accurate time on the device. There’s not much else to say about the management plane, it’s fairly self-explanatory. And here’s an example of management plane operations. A network engineer uses SSH to connect to the routers and do some configurations. For example, perhaps he configured OSPF and now the control planes of the routers are using OSPF to exchange routing information. This then determines how packets are forwarded in the data plane. And that’s a basic summary of how these three logical planes work. The data plane is really the essential one, it’s the reason we buy routers and switches. We want them to forward messages. But in order for the data plane to do its job, we need the control plane and the management plane. Before wrapping up this section I want to give a little bit more detail about the data plane. The operations of the management plane and control plane are usually managed by the CPU of the device. However, this is not desirable for data plane operations because CPU processing is slow, relatively speaking. So, instead a specialized hardware ASIC, application-specific integrated circuit, is used. These are chips built for specific purposes, such as forwarding frames in a switch. Here is a picture from Wikipedia of some ASICs. Let me use a switch as an example to demonstrate how this works. When a frame is received, the ASIC, not the CPU, is responsible for the switching logic. Remember, this is a specialized chip designed for forwarding frames, unlike the general-purpose CPU. Also, the MAC address table is stored in a kind of memory called TCAM, ternary content-addressable memory. TCAM allows for very fast lookups of MAC addresses. Definitely remember that term, TCAM. Also note that another common name for the MAC address table is CAM table, content addressable memory table. So, the ASIC feeds the destination MAC address of the frame into the TCAM, which returns the matching MAC address table entry, and then it is forwarded out of the appropriate interface. Note that modern routers also use a similar hardware data plane, with an ASIC designed for forwarding logic and the necessary tables stored in TCAM. So, to summarize this: when a device receives control or management traffic, destined for the device itself, it will be processed in the CPU. However when a device receives data traffic which should pass through the device, it is processed by the ASIC for maximum speed. Note that not all data plane traffic is processed by the ASIC, sometimes the CPU is necessary, but for now I won’t go any further into this topic. We can leave that for CCNP-level studies. So, the reason I spent all of that time going over the logical planes is that they are essential to understanding the next concept, software-defined networking. SDN is an approach to networking that centralizes the control plane into an application called a controller. Now, this isn’t a new concept for you. You should be familiar with it already from learning about wireless LAN controllers. When using a WLC, many functions are removed from the APs and centralized in the controller, so the APs role primarily becomes just forwarding traffic. Note that SDN can also be called software-defined architecture or controller-based networking. As I said earlier, traditional control planes use a distributed architecture, for example each router runs OSPF, shares routing information with other routers, and then independently calculates its preferred routes to each destination. An SDN controller centralizes control plane functions like calculating routes. Note that that is just an example, and how much of the control plane is centralized varies greatly. There are many different SDN solutions available, and the role of the controller and the network devices varies in each solution. A controller can interact programmatically with the network devices using APIs. APIs are application programming interfaces. I’m sure that many of you have heard of this term, even though you might not be 100% sure exactly what it means. I will dedicate a video to APIs later, so I’ll explain them at that point, although I will briefly introduce them in this video. So, here’s our traditional architecture. Note that for the purpose of this discussion I’m leaving the management plane out. We’re just focusing on the functions of the control plane. Now I’ve removed the control planes from R1 and R2. Then, we have a controller, an application running on a centralized server, and the control plane of the network is centralized here. Instead of R1 and R2 using OSPF to exchange routing information and then calculate routes, the controller communicates with R1 and R2 to program their data planes. So, instead of the control plane being distributed, each router having its own control plane, it is centralized in the controller. I’m only showing two routers here, but this could be a network with hundreds of routers, and this controller would operate the control plane of the entire network. The communication between the devices and the controller is done via what’s called the southbound interface, SBI. It’s called southbound because in diagrams we usually draw the controller on top and the network devices on the bottom, the south. Note that this term doesn’t refer to any physical interface on a device, but rather a software interface that is used to allow the controller and network devices to communicate. Now, before moving on to the next slide I want to repeat that, although this diagram shows a totally centralized control plane, in reality there are many different solutions. Some of them centralize the entire control plane, and some of them only centralize some functions of the control plane. So let’s look at SBIs, southbound interfaces. The SBI is used for communications between the controller and the network devices it controls. In the diagram, R1 and R2 are controlled by the controller, and the SBI is used to communicate between them. The SBI typically consists of a communication protocol and API, application programming interface. As I said before we’ll cover APIs in another video. But basically, they are used to facilitate data exchanges between programs. The controller is a program, and the network devices are programs too, running within their hardware. So, data is exchanged between the controller and the network devices, and for example an API on the network device can allow the controller to access information on them, control their data plane tables that are used to forward packets, etc. APIs play a big role in automating networking tasks, so we’ll go more in depth later. Here are some examples of south bound interfaces. OpenFlow, Cisco OpFlex, Cisco onePK, and NETCONF. I will cover some of these in more detail in later videos, but for now I recommend just memorizing their names and remembering that they are southbound interfaces, used by the controller to communicate with the devices it controls. In addition to the southbound interface, there is also a northbound interface. So, to review, using the SBI the controller communicates with the managed devices and gathers information about them. For example, which devices are in the network, the topology, so how the devices are connected together. Which interfaces are available on the device, their configurations, such as IP addresses etc, and much more information. That’s what the SBI is used for. The northbound interface, NBI, is what allows us to interact with the controller, access the data it gathers about the network, program the controller, and makes changes in the network via the SBI. We can tell the controller to make a change, and it will make the change via the SBI. So, here we have an app, and it will use the northbound interface to communicate with the controller. I explained the name southbound interface already, so I think you can guess why this is called the northbound interface. A REST API is used on the controller as an interface for the apps to interact with it. REST stands for representational state transfer, by the way. I’ll explain REST APIs more in the API video. Just note that REST isn’t a specific API, but a type of API. So, there is an interface on the controller. As I mentioned earlier, this isn’t a physical interface, but rather a software interface, it’s code that facilitates communication between the controller and the apps. So, the app sends a GET message to the API for example, which is a request for some data. The controller will reply with the requested data in a structured format like JSON or XML. Perhaps you’ve heard of JSON or XML before. I’ll make a separate video explaining them, but for now just understand that they are standard formats for structuring data. Why should data be structured? It makes it much easier for programs to use the data, because its stored in a standard format that is easy to interact with. Okay, that was a basic overview of the main components of SDN architecture. Before wrapping up the video, let’s spend some more time comparing it with traditional networks. So, we’ve been looking at SDN a lot, but networking tasks can be automated in traditional network architectures too. For example, scripts can be written, for example in Python, to push commands to many devices at once. The script can enable your computer to SSH to the device and then push whatever commands you want, perhaps configuring VLANs on many switches. Also, Python with good use of regular expressions can parse through show commands to gather information about the network devices. If you don’t know what regular expressions are you can google it, but basically they are just ways of searching for patterns in text. Look at this SHOW command for example, SHOW INTERFACES. This is in a human-readable format, it’s pretty simple for us to read through this and get what information we need. For example, if you want to know the bandwidth you can just look here and see BW 1,000,000 kilobits per second, so 1 gig. You can write a script that does the same, it could SSH to the device, use the SHOW INTERFACES command, and then parse through the output with regular expressions to find the information you want. However, the robust and centralized data collected by SDN controllers greatly facilitates these functions. The controller collects robust information about all devices in the network, providing a network-wide view. Also the northbound APIs allow apps to access information in a format that is easy for programs to understand, formats such as JSON or XML. No need to write scripts to parse through specific SHOW commands to get the information you want. Also, having this centralized data facilitates network-wide analytics, rather than getting information from individual devices and having to correlate the data yourself. SDN tools provide the benefits of automation without the requirement of third-party apps and scripts. This also means that you don’t need expertise in automation to make use of SDN tools. Many of them are very easy to use even for those who are unable to write their own scripts. However, APIs allow third-party applications to interact with the controller, which can be very powerful if you’re able to create your own apps. To summarize, although SDN and automation aren’t the same thing, SDN is just one aspect of network automation, the SDN architecture greatly facilitates the automation of various tasks in the network via the SDN controller and APIs. In this video we covered various topics related to network automation, and SDN in particular. We didn’t really go in depth, but that’s fine. This is an introductory video to the automation section of the course which will be 4 or 5 videos in total, so we have plenty of time to learn the details. But network automation is a paradigm shift compared to traditional networking, so instead of digging into the details right away I think it’s best to get a general overview of the important topics. In the next video we’ll look at data serialization, such as JSON and XML, in more detail. This is an important topic because it puts data in a format that is easy for programs to understand and work with. Okay, let’s go into the quiz for today, and make sure to watch until the end of the quiz for a bonus question from Boson Software’s ExSim for CCNA, the best practice exams for the CCNA. Okay, let’s go to quiz question 1. Which of the following are benefits of network automation? (select two). Pause the video now to select the best answers, select two. Okay, the answers are A, reduced human error, and B, reduced OpEx. Because automation means network engineers don’t have to spend so much time inputting commands into the CLI, human error such as typos can be reduced. Also, tasks can be achieved in a much shorter period of time, which reduces the OpEx, operating expenses, of the network. Okay, let’s go to question 2. Which of the following are SBIs? (select two). Pause the video now to select the best answers. Okay, the answers are C, OpenFlow and D, OpFlex. Other examples of SBIs given in this video are Cisco onePK and NETCONF. We’ll cover some of them in detail later, but for now just remember that they are SBIs, southbound interfaces. Okay, let’s go to question 3. Which of the following network functions would you expect to be centralized in SDN? Pause the video now to select the best answer. Okay, the answer is A, calculating routes. B, C, and D are all data plane functions, they describe functions involved in forwarding messages. A, calculating routes, is a function of the control plane and will likely be centralized in an SDN architecture. Okay, let’s go to question 4. What is the purpose of the SBI in SDN architecture? Pause the video now to select the best answer. Okay, the answer is C, to facilitate data exchange between the controller and network devices. For review, here’s that diagram again showing the role of the southbound interface. Regarding option B, it is the northbound interface, NBI, that facilitates data exchange between the controller and apps, not the SBI. Okay, let’s go to question 5. Which of the logical planes of networking does NTP’s function fit in? Pause the video now to select the best answer. Okay, the answer is B, management plane. NTP is used to provide accurate time for the device. It is not involved in the forwarding of messages, and it does not control how the data plane operates. Instead, it operates at the management plane. Okay, that’s all for the quiz. Now let’s look at a bonus question in Boson Software’s ExSim for CCNA.