Describe Cisco SD-WAN Architecture

0:00Hello and welcome to this ENS DWI SD WAN course. I'm Jeff Kish. That was a whole lot of acronyms. We are here to talk about Cisco's software defined wide area networking solution. SD WAN is not a Cisco only technology. It took the whole industry by storm probably about a decade ago at the point time that I'm recording this. It has been around for a little while although Cisco's attempts to create a solution and it took a little bit longer than maybe some of us realized it would. And so by the time they came out with SD WAN it was already a fairly mature product in the industry. And SD WAN came out of Cisco acquiring a company called Viptela. So this product very mature at this point, very established and very prevalent in our industry. The challenges of wide area networking can't be dismissed. There's a lot of problems with traditional WANs and we're about to jump into some of the details of that. But essentially it comes down to the fact that it's very complex to run and very expensive to run.

1:04Now if I just have a few sites with T1s or E1s going to some of these or maybe even Ethernet based MPLS circuits, it's not going to be that complex or that costly. So traditional WAN technology would work there. But when I want to deploy redundancy multiple routers at each side multiple circuits redundancy based on application where my voice over IP traffic should go. Where should my bulk internet downloads go? Where should my internet access be? Should it be locally? Should it be remote? Lots and lots of complexities and again costs associated with traditional wide area networking. SD WAN is going to attempt to fix all those problems for us. And again the purpose of this intro skill is to lay out the challenges of wide area networking. And then number one see how SD WAN as a general concept is designed to solve those problems and then we'll dive a little bit more specifically into Cisco's SD WAN solution. So buckle up we're gonna have a lot of fun in this course not only learning SD WAN conceptually but also jumping into the lab doing configurations and really getting comfortable with SD WAN deployments and management.

0:00Anytime we can connect our network from multiple sites to one another directly, we'll definitely do that. We will typically take advantage of fiber optics, such as metropolitan area networks. Maybe we can even bury our fiber ourselves and extend our local area network, and we could technically make this a wireless connection called a wireless local area network. But inevitably, we're going to have organizations who have sites and locations that are so far away that we have no option other than to rely on a service provider here in the middle.

0:34The service provider is going to leverage their own infrastructure and allow us to connect our different sites, and this is known as a wide area network. Wide area networking has been in use for many, many decades, and it is primarily used for us to connect our remote locations. Now these days, we might be able to take advantage of internet circuits and VPN s, but wide area networks not only connect our remote sites, they are known to be extremely reliable.

1:04That is the purpose of taking advantage of wide area networking. And so when we look at different topologies that we typically leverage when we 're using wide area networks, we have a lot of different options that primarily revolve around two categories point to point, as well as point to multi point. So a point to point technology would, for example, be a T1s and our E1s or T3s and our E3s, and it's going to allow me to have a router at one location, have a direct connection to a router at another location.

1:38So at this point, I'm going to be responsible for scaling this out to many locations. If I have a lot of remote sites, then I'm going to need my devices at each one of these sites to connect individually back to this maybe headquarters router. And so the more remotes we have, the less point to point connections make sense . Now certainly as I said in the intro video, if we have smaller architectures, maybe a handful of sites or maybe up to a dozen or so sites, then we can leverage traditional wide area networking, we can leverage point to point networks, but as we can tell, some of these things just don't scale out very well to hundreds and potentially thousands of different remote sites. And so instead, we might look at a point to multi point solution.

2:26And there's several of these, for example, we've got VPLS as one option, we've got Metro Ethernet. And certainly we have the option of using MPLS. The idea here is that the service provider is going to form some form of network. Maybe this is a layer two network. Maybe it's a layer three network depending on the technology that we choose. But the idea here is rather than having a bunch of point to point connections with my headquarters, I can now attach my headquarters to this networking domain. And then I can have all these remote sites also participate in the same network.

3:04What this allows is for me to not only share connections out from the headquarters to all of these other locations, but these locations can even communicate with one another if we choose to allow for that level of communication. So we're no longer talking about just single point to point connections. We're talking about a shared network on which we can potentially leverage broadcasts. And if we're running layer two, which makes it so we can easily run our own routing protocols, or if it's a layer three network like with MPLS, then we would share routes with the MPLS service provider.

3:43And either way, we're creating a larger domain for us to form networking with one that scales out a whole lot better. Now, a big problem as we scale out our wide area networks is going to come to the idea of redundancy. Because redundancy is going to require multiple devices, potentially at critical sites, we might not want to routers at every single remote location, but we might want them at headquarters and backup headquarters types of locations. And certainly here's the big one is redundant circuits, which typically is going to mean that we're talking about redundant service providers.

4:21We could use multiple circuits from the same service provider, but that in theory leaves us with a single point of failure potential. So we would probably want to look at multiple service providers when we're looking at critical services remaining up. When we start talking about this level of network and topology build out, we're introducing a whole lot of complexity. And furthermore, we're adding in a whole lot of choices that we're going to have to make that are not really easy.

4:55There's no simple answer to some of the choices. For example, let's say that I've got my headquarters location. I'm going to deploy my two different routers, but I want to make sure that I have redundancy with the service providers. So I have service provider A here, and I have service provider B down here. So if one goes down, the other one will pick up the slack and vice versa. But here's the question, what are these service providers? What type of service are they offering?

5:27Because if I'm looking at something like MPLS or VPLS or any of these other technologies, this is very, very expensive, although it is reliable, which is one of the key tenets of wide area networks. But we could also take a cheaper approach and do a VPN over the internet. And if so, that's going to be again much cheaper, but the reliability is a whole lot less. Unreliable per se, but we can't necessarily rely on it every single day, giving us the performance and the latency and all of the requirements that we have, which is especially relevant with voiceover IP.

6:06So now we look back at our topology, and we are immediately stuck with a really hard decision. One of these circuits should absolutely be MPLS, potentially in this scenario, at least because we care about the reliability. But should this backup service provider be MPLS, or should it be the internet? Do we want to spend a whole lot of money maintaining this backup service provider, especially as we scale it out, to all kinds of sites at our remote locations?

6:37Or do we want to go cheaper, but if the internet is what we choose, and our MP LS provider goes down, what will we do with voiceover IP traffic? These are some of the hard decisions that we have to make. So either way, where you can maybe get redundant connections to maybe individual service providers, usually we'll just do something like this, where we split the redundant connections between two devices, like our routers that we have drawn out over here.

7:08But now we have to think about how we're going to do this with the remotes, because the remote sites, now, maybe some of them are critical. Maybe some of them aren't. So maybe this is a critical location down here, and so we want to make sure that it's tied into both service providers. Maybe this one is in the same boat, but these up here, they are just going to rely on one service provider because we don't necessarily need redundancy at these locations. Maybe it's just a few users, and if they go down from a wide area networking perspective, it's not going to drastically impact my organization.

7:44So this is another set of decision points that we have to make is how do we connect our remotes into a redundant topology like this? But even just with four remotes in a headquarters site, look at the complexity that we've just created. And yeah, from a topology perspective, maybe it's a little bit complex, but specifically, we're talking about the routing complexity. This is going to be a little bit difficult for a couple of reasons. First of all, we have to make sure that we have proper failover in place.

8:16We have to make sure that we are routing correctly for the sake of efficiency. But now look at this as well. Where am I going to be able to deploy routing protocols like EIGRP and OSPF and possibly BGP in the right situation? Where do these protocols go? With MPLS, I'm going to have to form routing adjac encies. Usually we use OSPF or BGP, depending on the service provider for this, and that is certainly one option.

8:48But if my service provider B here is the internet, well, now I'm going to have to run something like the MVPN, which just adds more complexity. And I might not be able to make these two environments work very well together. Because the MVPN will run something like EIGRP, and this is going to be internal routes, meaning that they are going to be favored. Versus the service provider A being something like MPLS, which is shared routing, well, now this is going to be maybe OSPF external routes.

9:25And even if I run OSPF over DMBPN here, it's still going to be internal, and that's going to complicate things. Because it's supposed to be my backup service provider, and yet it might be preferred, strictly speaking, from a routing perspective. Furthermore, I have to worry about where VoiceOver IP is going to go. Do I want to make sure that VoiceOver IP goes one way and bulk internet traffic goes another way? And so we're going to have to look at source based or otherwise just policy based routing. As traffic comes into the wide area networking space, we're going to need to worry about redistribution of routes, and potentially even manipulating the administrative distance or the metrics that are used in order to figure out which path is best.

10:11This is a massive part of this conversation. We are developing very large, very complex wide area networks, and again, we have to make decisions where it's not always going to be clear what is the right solution. And these aren't even all of the challenges without diving into details. We're going to have problems with security. I'm sharing routes with my service provider here. I am sending traffic into a shared space, regardless of which vendor this is.

10:44How is security being addressed with wide area networking? It isn't natively encrypted. What about visibility? How can I make sure that the traffic that I'm sending into the wide area network is choosing the path that I think it's going to be choosing, and then manageability as well? This is a major concern. How do I manage all these devices? Am I still using CLI to log in to all of these individual devices and try to manage the domain myself? I need to make sure that I can wrap my arms around this topology, and not just in a way where I as the primary admin have full control over all of this, because I might leave the company one day or whoever that individual is.

11:27So how do I as an organization make sure that multiple managers can log in and make changes? Chances are individual CLI configurations isn't the best way to go there. So we have a lot of different challenges, not just what we just ended on here, but naturally adding in redundancy, adding in routing complexity, and let's keep in mind that cost is a big one as well. We want to reduce the cost if possible so that we can make proper decisions around the wide area network providers and technologies that we're choosing in order to maximize the benefits while minimizing the monthly cost that I have to spend on all of these circuits.

0:00So with all the problems identified, let's make a checklist for ourselves. That's going to hopefully serve as validation that SD-WAN is actually going to solve all these problems. So first of all, we mentioned a few at the end. We said manageability is a big one, and we can pretty well include visibility into that as well. Us being able to log into our wide area network as a single entity rather than a bunch of routers would be really cool, especially if it gives us visibility into what's going on there.

0:35So we put a little check box there and see if we can check it off. We also want to address security. We mentioned that there's two big problems with wide area networks from a security perspective. One is the fact that it's unencrypted. Meaning I'm just sending my traffic into a shared service provider space. We know that. There we go. If I have an MPLS provider, for example, I am sending the traffic unencrypted into a shared space, but I'm also, keep in mind, sharing routes.

1:09This is interesting. This is something that I have to do with layer three providers and technologies , which includes MPLS. And I don't necessarily love sharing routes. That's a little bit of personal private information to my organization, and yet I have to share that with an entity in hope that nobody within that entity goes rogue and tries to capture my traffic or capture my routes. For that matter, that the service provider doesn't make an honest mistake and send my routes and traffic to another customer. So there's another check box.

1:40We also saw that routing complexity is a big problem with traditional networks or traditional wide area networks. And that especially is going to be true when we look at our redundancy. So having many routers, many service providers going to be a big problem. We also want to make sure that we have application considerations. So an application per circuit, especially as it relates to voice over IP traffic, for example, as well as bulk internet traffic.

2:14And then lastly, we have cost considerations. So we would definitely want to address that in some fashion. And yeah, SD-WAN might cost more than a traditional network because we're deploying additional services. But can we overall reduce the cost of our wide area network in some form? Because if so, then that would pay for the upgrade on its own. All right. So now we want to look at our software defined wide area network or SD-WAN solutions.

2:45And keep in mind, a lot of this is going to be a benefit that belongs to SD-WAN technologies even outside of the Cisco product world. So yes, this course and this exam is all based on Cisco, but Cisco is not the only provider of SD-WAN. This is not a Cisco only set of technologies. Now Cisco would argue, and probably most of us, in the Cisco world would argue that Cisco's solution is superior for a lot of different reasons. If not, then why are we here learning about it and why are we deploying it into our networks at all?

3:20But understand again, where some things make sense to call proprietary to Cisco , other solutions do exist in other forms with different vendors. So when I look at SD-WAN solutions, one of the big things we want to provide is what we call a single pane of glass management system. So single pane management. This takes the form, or ideally would take the form of me as an admin and potentially other admins as well, logging into what I said earlier, which is my wide area network from an interface perspective, meaning that my wide area network back here with all of the complexities of connecting all of the different sites is going to be entirely managed through this interface.

4:13This means that I have one place to go to log in and make changes to my wide area network. So this is going to allow me to perform configuration changes. It's also going to allow me to have that visibility to look and see what exactly is happening inside of my network. Now this is important because we might have an admin leave. Maybe it's our primary admin that decides to go on and take a new job somewhere , which is fine. That happens. It's part of life. Now these other admins have a much better chance of being able to log into a what would otherwise be a very complex solution and simply gain access to the environment in that way and learn quickly if they need to do any learning.

4:58Now access to the single pane of management typically is going to take the form of a graphical user interface. However, in our modern world, we also want to see that we have API access, which I'll allow for programmability of our software defined solution, which is pretty typical with any kind of software defined architecture. So we can check off the manageability and visibility box. We've already greatly simplified our wide area network space just by giving us that single pane of management.

5:28Now next, we also are going to build our architecture on IP sec tunnels. This is going to accomplish quite a bit for us. In fact, a very important part of this architecture that we're building out is the fact that it's built on IP sec tunnels. Now there's a lot to unpack here and we'll be unpacking this over the course of time. But what we do with IP sec tunnels and just tunnels in general is we're going to form the concept of an overlay and an underlay.

6:00I always like to say that the overlay is the network I want, but the underlay is the network that I have. Without building tunnels, what we have or what we have is what we have. I can't build something else on top of it. However, I can build tunnels on top of my existing physical architecture and then I can run routing protocols across those tunnels, which is pretty interesting. Here's what happens here is we see an underlay that consists of our service provider routers.

6:35Then the overlay, which is my routers up here and my whole network that exists maybe at my headquarters, maybe at my remote sites. The IP sec tunnel is going to allow me to send traffic through the tunnel across this physical infrastructure that I have. This would be the architecture that I have all of these routers, but what I really want is for this device on the left, this edge router to talk directly to this edge router on the right.

7:06Pretty fascinating how what happens when we build out these software defined architectures using overlay technology, in our case IP sec tunnels. What does this accomplish? Well, a number of things. Again, you said there's a lot to unpack here. First of all, let's address things from a security perspective. From a security perspective, we have just encrypted our traffic. That is huge. We said the unencrypted traffic is a problem and normally I would just bring a packet in to my edge router and send it to my service provider router without encrypting it.

7:38This is why the service provider we hope is not only honest, but also doesn't make any mistakes in terms of sending my traffic to the wrong customer. Because keep in mind that they do have other customers down here and they are fully capable of accidentally sending my traffic to the wrong customer, which might be some very sensitive information. The encrypted traffic is great because now it's using IP sec. But beyond that, I can also do direct routing.

8:12In a traditional MPLS network, again, if I'm handing my packet off with a destination of a network over here, well, in order for this router to send to this network, it needs to know where that network is, which is why I have to share routes. I have to tell this router, "Hey, I've got these private internal routes and if you see traffic for it, you need to send it to me." Well, that isn't required anymore because this router just needs to know how to get to the edge router, whichever one of these is technically the service provider edge in this scenario.

8:45That's all it has to know. Which means that I can bring traffic in and again from an overlay perspective, send it directly to the other side. Meanwhile, thanks to the power of encapsulation and tunnels, these underlay devices don't need to know anything more than their own network. So this is huge security. We've just checked that off from both perspectives. We're now encrypting our traffic and we're no longer sharing routes with our service provider. On top of that, our routing complexity, our routing environment has actually just gotten a whole lot better because, again, without having to share my routes, I don't have to do any route sharing anymore, and the ability for me to perform direct routing protocol adjacencies, this is huge.

9:35Remember the example we gave where we had external redistributed routes versus internal routes depending on the technology we chose. Well, now there is no redistribution required because I can run the same protocol everywhere. This massively simplifies my architecture. Furthermore, we mentioned that we want to control which applications use which circuit. Now, we can't go into the details of this until later on as we dig into the weeds, but what I can say is that because of this management pane, we have a whole lot more direct access as far as sending applications per circuit.

10:17So it's going to use the same concept as policy-based routing except it's managed. You and I, as an admin, we don't have to worry about forming very complex policy-based routing policies, which is very cool. So the routing complexity has been greatly simplified, both from something we can tell directly here as we have laid out using the same protocols everywhere, not having to redistribute, but also a little bit of trust-based teaching at this point that eventually we will see how the policy-based routing more or less is handled via the solution.

10:53Now, lastly, the cost. This is an interesting part of the conversation because, like we mentioned, SD- WAN hardware typically is going to cost more, not just because it's running different hardware, but also because there's going to be software costs, there's going to be licensing costs, it does require more cost. And yet, what we'll find is that we can actually overall reduce the cost. Now, this happens in a couple of different ways. First of all, when we lower complexity, this is going to naturally lead to cost savings, even if it's kind of difficult to track that down sometimes.

11:28But if we think about it, I don't need nearly the size of the team dedicated to working on things. Now, we're not saying we can go out there and start firing people, but what we are saying is we can redirect the team to other activities. We can be more efficient, and if we do our calculations correctly, we should be able to translate this efficiency into cost savings. Now the other way is a little bit more tangible. Remember those service providers that we talked about earlier, how MPLS typically involves a lot more reliability.

12:04Well, that's great and all, except it also comes at a much larger cost. So I might still deploy MPLS to one of these service providers, but now I don't need to worry nearly as much about making sure VoiceOver IP is taken care of. I can deploy the internet as a backup, swing my VoiceOver IP traffic down, and because routing is handled for me a little bit more, I can swing that traffic right back. So that's very important. But some organizations have even been able to remove MPLS and do dual internet circuits.

12:39This makes the wide area network enormously less expensive, and the reason we can do this is because we can always favor the more reliable, better performing internet circuit depending on the day. Now we want to be very careful. I am not saying that this is the right answer. In fact, very rarely it is the right answer, but it is something that is now technically possible. So we can build SD-WAN connections directly over internet circuits, regardless of whether it's in both locations or just in one, either way, that's a very tangible reduction in monthly recurring costs.

13:13So these are the ways that we have chosen to address the challenges of wide area networking and manageability, security, routing complexity, and yes, even cost overall can be seen as being more effective by deploying SD-WAN technology.

0:00Now that we know the benefits that SD-WAN can provide, it's time to talk about Cisco Solution, which is simply known as Cisco SD-WAN. Cisco's SD-WAN product came after they developed their own product, which is known as I-WAN. And this was fairly short-lived. Cisco realized that other vendors already had pretty good solutions out there, and so they just decided to go purchase another company called Viptela. And the Cisco SD-WAN solution came from the Viptela acquisition.

0:31And we'll see why this matters coming up here, mostly from a nomenclature or naming perspective. But at the same time, at this point, it's been many, many years, and it really is now Cisco's SD-WAN solution. We're not going to expect to see much in the way of references to Viptela anymore. Now when we look at the Cisco SD-WAN solution, they divide their solution into four planes of operation. If we think about the networking side, we typically think about two primary planes with control and data plane, sometimes the management plane.

1:03And that's what we're going to see here, other than that Cisco is really trying to create its own architecture rather than trying to tie back to anything in the existing networking. That said, we certainly do have our data and control planes of operation. And specifically, data plane of operation, this is going to define the traffic paths. And as we'll see, this is where the IPsec tunnels are formed. We also have the control plane and the control plane defines the route propagation.

1:37And so far, this again feels like traditional networking, which is pretty good. Then we have the management plane of operation. And this is specifically going to tie back to that single interface, that single point of management, and this is going to be where we define how we manage things, whether through the graphical user interface or possibly APIs. Now lastly, this is the unique part of SD-WAN is that Cisco creates for us the orchestration plane.

2:13Orchestration is kind of an interesting one. We say, well, normally this isn't required. Why do we need this here compared to traditional networking? Well, because orchestration is going to help us with onboarding. We're talking about a software defined solution here. We're talking about hardware that needs to more or less create its own network on top of itself. But if I'm going to deploy a router out into the world, maybe a new remote site , how does it download all of this information?

2:44How does it even know to join the wide area network that belongs to my organization as opposed to other organizations? So that is the onboarding process. And we're going to require operation within this plane in order to bring everything online. So let's go into a little bit of details here. And we'll dive deeper and deeper as we go through the course. We'll look at the data plane of operation, our primary device that's going to participate in the data plane would be our edge devices. Now I'm using this word device.

3:16Cisco will use the word platform. Really these are routers. So always keep that in mind that we're primarily building this on Cisco router types of devices. From a legacy perspective, I always like to provide a little bit of context here. This used to be known as either a V edge or a C edge. Now Cisco has started to get rid of some of this terminology, but when we see this in documentation, it's going to be important for us to know what we're talking about.

3:47A V edge, that little V is in reference to Viptela. That means that we're deploying Viptela hardware. Now Cisco acquired Viptela as an SD-WAN provider and one that happened to make router hardware. Well as you might imagine, Cisco said, "Okay, that's great. On day one, we absolutely need to keep producing and selling and supporting V iptela hardware, but we're kind of known for making routers ourselves." And so once we get SD-WAN technology baked into iOSXE, our routing platform of choice for enterprise networks, then we're not going to continue to sell V edges anymore.

4:24And that's exactly what happened. So what Cisco did was they created an iOSXE flavor that can handle SD-WAN and they called that the C edge where now the C is short for Cisco. Well that's well and good other than again. We don't really sell V edges anymore and so Cisco got rid of the term C edge instead. We're primarily going to refer to this simply as, well actually let's do it like this, it's known as an SD-WAN edge device.

4:56And we're going to see that a lot of our older nomenclature or older titles have been replaced by something that sort of follows this format. So what exactly is this data plane all about? Well again, we're typically going to run these in the modern network on catalyst 8000 routers. Cisco calls these edge platforms, but either way the catalyst 8000s is what we 're typically going to run on SD-WAN on, although we could run this also on integrated services routers and aggregation services routers and we'll talk about the details of that coming up.

5:32But interestingly this can be physical or it can actually be virtual. So we could deploy cloud routers into cloud spaces and allow them to participate by building out those IP sec tunnels. Very cool and we're going to leverage this virtual concept especially for creating labs. But keep in mind in the real world we can deploy these into cloud spaces as well. So both of these are going to be good use cases for virtual SD-WAN edges.

6:04And importantly they are going to form as we mentioned the IP sec tunnels. The IP sec tunnels operate inside of the data plane. So when we're looking at our SD-WAN edge here as well as the IP sec tunnels these are facets of the data plane. Now as we go through these we can now look at the non data planes of operation including the control plane. So the control plane is going to run not as a router but this is going to be deployed as a virtual machine.

6:39Meaning I might deploy this into my own data center or into a cloud space but either way the control device of choice is going to be a virtual machine and that device is known as the SD-WAN controller. Now if you've studied SD-WAN before you probably weren't expecting me to say SD -WAN controller but again Cisco has rebranded things. This used to be known as the V smart. Where the little V is once again part of that Viptela acquisition but Cisco left this alone for a very long time.

7:12It's only really recently that they started to call things by different names. So it used to be the V smart now it's the SD-WAN controller and this is going to be responsible for route propagation. Now when we talk about route propagation we're not talking about OSPF or EIGRP we're primarily talking about OMP here. We're going to be using the overlay management protocol which is going to allow us to propagate SD-WAN control information to all of the devices.

7:46From here we can talk about the management plane and the management plane once again is going to have well first of all we deploy this as a virtual machine into our network and this is known as the SD-WAN manager. So far the names make sense. Managers part of management plane of operation the controller is part of the control plane of operation and nothing too complex here but just wait a moment until we get to the orchestration plane but either way the SD-WAN manager also had a name that we used to call this which is V-Manage.

8:28And again Cisco only recently made that change. There's a whole lot of documentation and software references to be managed we do need to know both names in all of these cases. So the idea here is that once again we'll log in either via graphical user interface or API and importantly it's a single way for us to manage the entire SD-WAN environment. However as you can imagine we'll want to deploy a pair of these for the sake of redundancy.

8:59Now lastly this is the one I was joking about. Now we have to worry about the orchestration plane and this is going to be known as an SD-WAN validator. Oh yeah where did that name come from? Well Cisco decided to come up with it apparently and that's perfectly fine. This used to be known as a V-Bond and the idea with calling it the V-Bond is that it was bonding a new device into the network via this onboarding process.

9:32So Cisco came up with the term validator because well we need to make sure that the device is supposed to be on our network and the device needs to make sure it's attaching to the same network or the correct network and so yeah there's some validating that happens during this process but just keep in mind if we see SD-WAN validator this doesn 't tie to a validation plane operation it's going to map to the orchestration plane of operation. So from here again the main thing we're focusing on I won't write it again it's the fact that we're trying to onboard our devices and this is actually the first point of authentication as well.

10:10So as I keep saying we need to make sure that this device attaches to the correct network and we as the network don't want random devices attaching to us and becoming part of our wide area network security must be baked into the solution from the ground up and fortunately it is. So I highly recommend coming out of this conversation that we have a good sense of which devices belong to which planes of operation and I would highly recommend also knowing the old names the V-Bond the V-Manage the V-Smart as well as the V-Edge and the C-Edge concepts.

0:00All right, we are going to end this skill with a challenge. In fact, we're going to find that we end every single skill with a challenge. I highly recommend taking the time to do every single challenge. It's going to help us to reinforce the knowledge that we've learned. Sometimes it will be something like an interactive quiz like this, interactive being that we'll explain the answer afterwards. We might be a lab, we have to create a lab topology and perform configuration. It could be anything. But the idea here, generally speaking, is that we want to again reinforce what we've learned and make sure that we've got it all down before moving on.

0:31Now, when we do a quiz like this, I'm going to ask the question. I encourage you to pause the video. I'm not going to leave a whole lot of time to answer it. So pause the video, make sure you can answer it yourself, and then unpause the video. And again, we'll go through the answer. So first up, out of three questions here, what is the tunneling mechanism used in the Cisco SD-WAN solution? Tunneling is a major part of the SD-WAN solution. We're going to have the underlay. That would be the service provider network.

1:01And then we're going to build an overlay on top of this. And this overlay is going to be built with IPsec tunnels. This is very important. IPsec is what we're going to be using. We're not using VXLAN, which is a layer two tunneling mechanism. And what we'll find is we can actually use GRE. That actually is an option, but it's not one we're going to often deploy because it doesn't give us security. And that is one of our primary concerns here. And so we're going to deploy our Cisco SD-WAN solutions using IPsec tunnels.

1:33Question two, how is the Cisco SD-WAN solution managed by admins? Well, if you're like me, you love, or at least enjoy somewhat, logging in via the CLI to a network device. And we know that our wide area networks might have a lot of devices. This doesn't scale. It's a problem that exists with our modern networks. And so we're not going to rely on this. Instead, what we're going to do is we're going to insert a middle software package that then pushes configurations via APIs.

2:07And so the idea here is we will be logging in to a software package that we now know is known as the SD-WAN manager, formerly known as VManage. And furthermore, we can use graphical user interface, or we could actually leverage APIs in order to access the software. There will be CLI commands that we can use to log in and troubleshoot, but that 's not going to be our primary mechanism for managing the overall solution. Instead, we'll deploy SD-WAN manager as a virtual machine into our environment.

2:41And then we will use that to access the entirety of the configuration and manageability of all of the nodes in our software defined wide area network. All right, question number three, and it is the last one. Which Cisco SD-WAN device helps with the onboarding process for new devices? Well, the answer here is going to be D, the SD-WAN validator, which is part of that orchestration plane. This used to be known as the V-bond. And the idea here is that as new devices come online, we've got to find the rest of the network way over here. And so it's going to reach out to the V-bond and the V-bond will connect this device to the proper network.

3:24Now it is important, as we've said, that we know which plane of operation each one of these devices operates within. There's four planes and four devices, so it matches up well. And furthermore, I'd recommend knowing the legacy names like V-bond. So as we go through these, the edge used to be known as the V-edge for the Vipt ela hardware, the C-edge running iOSXe. And this belongs in the data plane. The SD-WAN controller used to be known as V-Smart. And as the name implies, this is part of the control plane. And lastly, the SD-WAN manager used to be known as V-Manage. And that's part of the management plane of operation. So as we get to the end of a quiz like this, what I would recommend is using this as a guide to let us know, are there any gaps in our knowledge that we should go back and shore up before moving on? So for example, we don't maybe know all four of the planes of operation or this made us aware that we don't quite have the legacy names memorized. We should go back and review that content as well as any other content that we feel like we need to know better before moving on to the next skill. I hope this has been informative for you and I'd like to thank you for