Cisco SD-WAN architecture and components - Cisco Tutorial

- [Instructor] In this lesson, we're going to talk about the SD-WAN architecture and components. Now, when I first meet a network engineer, one of the questions I like to first ask them is, how do you handle your greenfield deployments? Do you do the configuration by head from CLI, or do you open up a text file, or CFG file and just change some variables? Or do you use tools like Prime Infrastructure or DNA Center? Or other tools like Ansible to kind of help with the provisioning of your configuration? Now, while you may be able to provision things effectively from that standpoint, the other thing that I found is the template configuration will change over time. And not specifically the template itself, but the actual configuration on the device. So for example, I could have a problem on R1 with OSPF that's going to require me to log in and make a change to the route redistribution. And then something could happen a little bit later on, where on R3, I have to log in and make a change to the QoS policy. And then something could happen on R4 that's going to require me to log in and make a change to the ACL. And you can see how this scenario could proliferate where I'm constantly making changes to all of the routers in my environment. And in essence, the thing that I've now found is when I look at my environment, I have now created snowflakes. Now snowflakes are pretty in the wintertime and everything else, but they're pain at three o'clock in the morning when you're trying to reverse engineer what has happened. And this is because of the fact that each configuration has deviated. So how do you audit your devices and make sure that they're compliant? Because that's a key thing. I like to have the same operational playbook for troubleshooting things, right. And so, that keeps things happy because I hate, hate with a passion, it's raining and it's Thursday, so I'm turning right, versus the sun shining and it's Wednesday, so I'm going to turn left. I want to run the same playbook across all my networks. And this is important when you start to think about how we have the configuration. So within all these devices, the routing configuration, the security policy, the forwarding policy, or the QoS or QoS policy is decentralized in the fact that that configuration resides on each box, right. So that's one thing that's kind of different. So what we've done with our solution is we've taken that logic and we moved that up into a management cloud. Now, within that management cloud, we have secured it with a DTLS tunnel. So that's all these little connections right here is encrypted in a DTLS tunnel. So that provides us the safety and security that we know and love. The next big thing is that this is now going to provide us a centralized configuration repository. It's going to be the single source of truth. So if you ever have problems and need to go through the process of reprovision a new edge device, the configuration is right there. It's going to be super fast and super easy to deal with, right. And then the other thing is, is not only is it a configuration repository, it's got a built-in network monitoring system. Now, the people who developed the solution are ex Cisco and they worked in TAC and it worked in the service provider. So what that means is that they are going to work on increasing scalability from the service provider space, and then they're going to work on reducing complexity from the TAC space. So this is one of the key benefits, is the administration of the solution unto itself. And so, that means that all of the routing, the security policy, the forwarding policy, and QoS policy is all going to reside inside of this management cloud, okay. Now, in addition to providing the centralized administration model, we've also gone and built out an IPsec fabric that allows us to run across any transport connectivity you want. Whether that's private MPLS, layer two or layer three VPN, or if you want to run that across the public internet, You're more than able to do that, right. So we're able to provide that fabric for you for that end-to-end. That allows you to choose whatever transport you want based off of a variety of different factors, right. You can get into whatever you want for engineering. It could be based off of cost, availability, a variety of different ways for choosing your transport. Now the other thing worth pointing out within this fabric is we allow probability via REST APIs on the controllers, specifically, that'll be towards the vManage. Now, you can log into the vManage for the configuration and stuff like that. Or if you want to do things pro programming, you can push your REST APIs towards your vManage itself. Some customers are able to manage their SD-WAN network completely by APIs. So we have given 100% support in our API space to make sure that we can enable that programmability. Now, the first function we're going to talk about is the vBond, okay. And so the vBond, the first and foremost goal is it's going to be your first point of authentication. So what does that mean? It means that when a device actually comes online, the first thing it's going to do is it's going to connect to the vBond and authenticate with it. Now the method of connectivity is based off certificates. And we started using a TPM chip, or a trusted platform module chip, which is where we actually are going to store the certificates. Now, the certificates that we use by default are going to be the certificates that are installed at the time of manufacturing. Now, on top of that, in the software is the root certificate, CA certificate, so that we are then able to authenticate the certificate itself. That way we can verify that the hardware is authentic Cisco, and we can verify that the software is authentic Cisco. Now, in addition to doing that authentication of the edge device at the vBond, life wouldn't be fair if we didn't do the authentication of the vBond at the edge device. And by doing that authentication, what that does is that prevents things like man-in-the-middle attacks from happening because we've authenticated both directions. So we know that that connection is good. Now the next thing, is is once we've done that authentication, we are going to orchestrate connectivity. Now, I kind of joke around and say orchestrate is a fancy term for basically we're going to build that connection up to the vBond, we're going to authenticate with each other, and then at that point, the vBond is going to orchestrate or redirect our connections to the appropriate vManage as well as the appropriate vSmart to have our connection. Now, once we've orchestrated and handed off that connection, we are going to go through the process and tear down that vBond connections. The last thing that we do with the vBond is it's helpful for when we have a firewall in the middle that might be performing network address translation. So we are able to detect using RC STUN mechanisms whether or not there is a public IP and a private IP address. So if there's been a change in the IP addressing, we can detect that, and that happens on the vBond. So there will be a session built up across all the transports that we're using for the data plane. The next one is the vManage. And so what the vManage is, it is going to be the repository for all of your policies and templates. And the templates basically translates into the actual device configuration of all of your edge devices, as well as the configuration for your vSmarts. In addition to this, if you wanted to make API calls or changes through programmatic interfaces, all of that is going to be directed at your vManage. So this is where the REST API calls are going to be directed. So you'll do that through HTTPS, you'll get a authentication token, and then you'll start making the appropriate API calls towards this. Now, the other benefit towards the vManage is this is going to be your network management system. So when you have issues, this is where you are going to go for any of your troubleshooting or monitoring, is going to be at your vManage because that's your network management system, okay. So that is the role of the vManage. The next thing we're going to talk about is the Cisco vSmart, and this is responsible for handling the overlay routing. Now, when I first got into networking, they talked about layer two with hubs, and switches, and bridges. And that was basically, again, how do we handle the layer two traffic. And then I learned about things like IGRP, RIP and OSPF, and then this new fancy thing called EIGRP, which was basically by layer three routing. And I thought I was golden. I'm ready to go tackle the world. And then somebody says, "Whoa, whoa, what about these things called IPsec tunnels, right?" I'm like, "Tunnels, what's that?" And it's like, "Well, it's a way to get a packet from point A to point B across a whole batch of stuff." And I'm like, "Okay." So then I had to learn tunnels. Now the thing that you have to realize that's important about tunnels is in order for them to work, they have to ride on top of the layer three information. Now that routing is actually what we refer to as underlay routing, okay. Now, when I came a little bit later on, I realized that okay, with GRE tunnels, you can actually run routing protocols over your GRE tunnels. You can run BGP, or EIGRP, or OSPF. And when you do that, you have to be careful of things like routing loops or recursive routing problems that could occur. But in essence, that is where your layer three runs on top of your tunnels, and that is overlay routing. And so that is exactly what the vSmart is responsible doing. It's controlling those routes that you're going to be sending across the IPsec fabric, right. Is what that is going to be responsible for. Now, the other thing that it's going to be responsible for is handling the encryption between your edge devices. And the last component is it will propagate any of the policy it has for handling of the network traffic. So the vManage will make the configuration in the policies, but then the policies will either apply on the vSmarts or they'll get cascaded down to the edges. And the last plane that we have is the data plane. And quite simply what the data plane is, it's responsible for doing the encryption and the decryption of the traffic. So we'll decrypt the traffic as it comes across the WAN. And then as we come in from the LAN, we'll actually go through the process of encrypting the traffic. Now we have two platforms to choose with. We have the physical way that we can take this, or we have the virtual. So start to with, when we talk about the physical platform, we have the vEdge platform, which came over with the initial acquisition. We also have the IS which runs one type of operating system. And then we also have the other platforms which are IOS XE based, right. So those are going to be the ISR 1K, the ISR 4K, the ASR 1000, or the Catalyst 8000. So those are all going to be physical boxes we have. Now, in addition, in some of our hardened industrial routers, we have the capability of running SD-WAN on those too, such as the IR 1100. In the virtual space, we have basically three platforms we can run off of. We can run the vEdge Cloud, we can run the CSR 1000v, or the Catalyst 8000v. Now the Catalyst 8000v, if I was going to be deploying new stuff, would be the direction I would take. And the reason for it, it runs the exact same code as what is on the physical Catalyst 8000 with a couple additional drivers for the virtualized platform. And when we're talking about virtualized platform, it's not just running on a ESXi host