Describe Cisco SD-WAN Architecture

0:00Hello and welcome to this ENS DWI SD WAN course. I'm Jeff Kish. That was a

0:06whole

0:07lot of acronyms. We are here to talk about Cisco's software defined wide area

0:11networking solution. SD WAN is not a Cisco only technology. It took the whole

0:17industry by storm probably about a decade ago at the point time that I'm

0:22recording this. It has been around for a little while although Cisco's attempts

0:26to create a solution and it took a little bit longer than maybe some of us

0:31realized it would. And so by the time they came out with SD WAN it was already

0:35a

0:35fairly mature product in the industry. And SD WAN came out of Cisco acquiring a

0:40company called Viptela. So this product very mature at this point, very

0:45established and very prevalent in our industry. The challenges of wide area

0:50networking can't be dismissed. There's a lot of problems with traditional WANs

0:55and we're about to jump into some of the details of that. But essentially it

0:59comes 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

1:08even Ethernet based MPLS circuits, it's not going to be that complex or that

1:14costly. So traditional WAN technology would work there. But when I want to

1:18deploy redundancy multiple routers at each side multiple circuits redundancy

1:23based on application where my voice over IP traffic should go. Where should my

1:27bulk internet downloads go? Where should my internet access be? Should it be

1:31locally? Should it be remote? Lots and lots of complexities and again costs

1:36associated with traditional wide area networking. SD WAN is going to attempt to

1:41fix all those problems for us. And again the purpose of this intro skill is to

1:45lay out the challenges of wide area networking. And then number one see how

1:49SD WAN as a general concept is designed to solve those problems and then we'll

1:54dive a little bit more specifically into Cisco's SD WAN solution. So buckle up

2:00we're gonna have a lot of fun in this course not only learning SD WAN

2:03conceptually but also jumping into the lab doing configurations and really

2:08getting comfortable with SD WAN deployments and management.

0:00Anytime we can connect our network from multiple sites to one another directly,

0:05we'll definitely do that.

0:07We will typically take advantage of fiber optics, such as metropolitan area

0:11networks.

0:12Maybe we can even bury our fiber ourselves and extend our local area network,

0:17and we could technically make this a wireless connection called a wireless

0:21local area network.

0:22But inevitably, we're going to have organizations who have sites and locations

0:27that are so far away that we have no option other than to rely on a service

0:31provider here in the middle.

0:34The service provider is going to leverage their own infrastructure and allow us

0:38to connect our different sites, and this is known as a wide area network.

0:43Wide area networking has been in use for many, many decades, and it is

0:48primarily used for us to connect our remote locations.

0:53Now these days, we might be able to take advantage of internet circuits and VPN

0:57s, but wide area networks not only connect our remote sites, they are known to

1:02be extremely reliable.

1:04That is the purpose of taking advantage of wide area networking.

1:08And so when we look at different topologies that we typically leverage when we

1:12're using wide area networks, we have a lot of different options that primarily

1:16revolve around two categories point to point, as well as point to multi point.

1:23So a point to point technology would, for example, be a T1s and our E1s or T3s

1:26and our E3s, and it's going to allow me to have a router at one location, have

1:34a 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

1:47locations. If I have a lot of remote sites, then I'm going to need my devices

1:51at each one of these sites to connect individually back to this maybe

1:54headquarters router.

1:55And so the more remotes we have, the less point to point connections make sense

2:01. Now certainly as I said in the intro video, if we have smaller architectures,

2:05maybe a handful of sites or maybe up to a dozen or so sites, then we can

2:08leverage traditional wide area networking, we can leverage point to point

2:12networks, but as we can tell, some of these things just don't scale out very

2:16well to hundreds and potentially thousands of different remote sites. And so

2:22instead, 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

2:30got Metro Ethernet. And certainly we have the option of using MPLS.

2:37The idea here is that the service provider is going to form some form of

2:42network. Maybe this is a layer two network. Maybe it's a layer three network

2:46depending on the technology that we choose.

2:49But the idea here is rather than having a bunch of point to point connections

2:53with my headquarters, I can now attach my headquarters to this networking

2:57domain. And then I can have all these remote sites also participate in the same

3:04network.

3:04What this allows is for me to not only share connections out from the

3:10headquarters to all of these other locations, but these locations can even

3:15communicate with one another if we choose to allow for that level of

3:18communication.

3:20So we're no longer talking about just single point to point connections. We're

3:25talking about a shared network on which we can potentially leverage broadcasts.

3:31And if we're running layer two, which makes it so we can easily run our own

3:35routing protocols, or if it's a layer three network like with MPLS, then we

3:39would share routes with the MPLS service provider.

3:43And either way, we're creating a larger domain for us to form networking with

3:48one that scales out a whole lot better.

3:51Now, a big problem as we scale out our wide area networks is going to come to

3:56the idea of redundancy.

3:58Because redundancy is going to require multiple devices, potentially at

4:03critical sites, we might not want to routers at every single remote location,

4:08but we might want them at headquarters and backup headquarters types of

4:12locations.

4:12And certainly here's the big one is redundant circuits, which typically is

4:16going to mean that we're talking about redundant service providers.

4:21We could use multiple circuits from the same service provider, but that in

4:25theory leaves us with a single point of failure potential.

4:29So we would probably want to look at multiple service providers when we're

4:33looking at critical services remaining up.

4:37When we start talking about this level of network and topology build out, we're

4:43introducing a whole lot of complexity.

4:47And furthermore, we're adding in a whole lot of choices that we're going to

4:52have to make that are not really easy.

4:55There's no simple answer to some of the choices.

4:57For example, let's say that I've got my headquarters location.

5:01I'm going to deploy my two different routers, but I want to make sure that I

5:05have redundancy with the service providers.

5:08So I have service provider A here, and I have service provider B down here.

5:14So if one goes down, the other one will pick up the slack and vice versa.

5:20But here's the question, what are these service providers?

5:24What type of service are they offering?

5:27Because if I'm looking at something like MPLS or VPLS or any of these other

5:31technologies, this is very, very expensive, although it is reliable, which is

5:37one of the key tenets of wide area networks.

5:41But we could also take a cheaper approach and do a VPN over the internet.

5:46And if so, that's going to be again much cheaper, but the reliability is a

5:50whole lot less.

5:52Unreliable per se, but we can't necessarily rely on it every single day, giving

5:58us the performance and the latency and all of the requirements that we have,

6:03which is especially relevant with voiceover IP.

6:06So now we look back at our topology, and we are immediately stuck with a really

6:11hard decision.

6:13One of these circuits should absolutely be MPLS, potentially in this scenario,

6:17at least because we care about the reliability.

6:21But should this backup service provider be MPLS, or should it be the internet?

6:26Do we want to spend a whole lot of money maintaining this backup service

6:30provider, especially as we scale it out, to all kinds of sites at our remote

6:35locations?

6:37Or do we want to go cheaper, but if the internet is what we choose, and our MP

6:42LS provider goes down, what will we do with voiceover IP traffic?

6:47These are some of the hard decisions that we have to make.

6:50So either way, where you can maybe get redundant connections to maybe

6:55individual service providers, usually we'll just do something like this, where

7:00we split the redundant connections between two devices, like our routers that

7:06we have drawn out over here.

7:08But now we have to think about how we're going to do this with the remotes,

7:12because the remote sites, now, maybe some of them are critical.

7:16Maybe some of them aren't. So maybe this is a critical location down here, and

7:21so we want to make sure that it's tied into both service providers.

7:24Maybe this one is in the same boat, but these up here, they are just going to

7:29rely on one service provider because we don't necessarily need redundancy at

7:34these locations.

7:36Maybe it's just a few users, and if they go down from a wide area networking

7:40perspective, 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

7:48connect our remotes into a redundant topology like this?

7:52But even just with four remotes in a headquarters site, look at the complexity

7:57that we've just created.

8:00And yeah, from a topology perspective, maybe it's a little bit complex, but

8:04specifically, we're talking about the routing complexity.

8:08This is going to be a little bit difficult for a couple of reasons. First of

8:12all, 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.

8:22But now look at this as well.

8:24Where am I going to be able to deploy routing protocols like EIGRP and OSPF and

8:30possibly BGP in the right situation?

8:34Where do these protocols go? With MPLS, I'm going to have to form routing adjac

8:40encies.

8:41Usually we use OSPF or BGP, depending on the service provider for this, and

8:46that is certainly one option.

8:48But if my service provider B here is the internet, well, now I'm going to have

8:54to run something like the MVPN, which just adds more complexity.

8:57And I might not be able to make these two environments work very well together.

9:04Because the MVPN will run something like EIGRP, and this is going to be

9:09internal routes, meaning that they are going to be favored.

9:13Versus the service provider A being something like MPLS, which is shared

9:19routing, 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

9:31that's going to complicate things.

9:32Because it's supposed to be my backup service provider, and yet it might be

9:36preferred, strictly speaking, from a routing perspective.

9:40Furthermore, I have to worry about where VoiceOver IP is going to go.

9:43Do I want to make sure that VoiceOver IP goes one way and bulk internet traffic

9:46goes another way?

9:48And so we're going to have to look at source based or otherwise just policy

9:52based routing.

9:54As traffic comes into the wide area networking space, we're going to need to

9:58worry about redistribution of routes, and potentially even manipulating the

10:03administrative distance or the metrics that are used in order to figure out

10:09which path is best.

10:11This is a massive part of this conversation. We are developing very large, very

10:17complex wide area networks, and again, we have to make decisions where it's not

10:23always going to be clear what is the right solution.

10:27And these aren't even all of the challenges without diving into details. We're

10:31going to have problems with security.

10:35I'm sharing routes with my service provider here. I am sending traffic into a

10:40shared space, regardless of which vendor this is.

10:44How is security being addressed with wide area networking? It isn't natively

10:48encrypted. What about visibility?

10:51How can I make sure that the traffic that I'm sending into the wide area

10:54network is choosing the path that I think it's going to be choosing, and then

10:58manageability as well?

11:01This is a major concern. How do I manage all these devices? Am I still using

11:06CLI to log in to all of these individual devices and try to manage the domain

11:12myself?

11:13I need to make sure that I can wrap my arms around this topology, and not just

11:18in a way where I as the primary admin have full control over all of this,

11:23because 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

11:32make changes? Chances are individual CLI configurations isn't the best way to

11:37go there.

11:38So we have a lot of different challenges, not just what we just ended on here,

11:43but naturally adding in redundancy, adding in routing complexity, and let's

11:48keep in mind that cost is a big one as well.

11:52We want to reduce the cost if possible so that we can make proper decisions

11:56around the wide area network providers and technologies that we're choosing in

12:01order to maximize the benefits while minimizing the monthly cost that I have to

12:07spend on all of these circuits.

0:00So with all the problems identified, let's make a checklist for ourselves.

0:06That's going to hopefully serve as validation that SD-WAN is actually going to

0:11solve all

0:12these problems.

0:13So first of all, we mentioned a few at the end.

0:16We said manageability is a big one, and we can pretty well include visibility

0:21into that

0:22as well.

0:23Us being able to log into our wide area network as a single entity rather than

0:28a bunch of

0:29routers would be really cool, especially if it gives us visibility into what's

0:33going on

0:34there.

0:35So we put a little check box there and see if we can check it off.

0:38We also want to address security.

0:40We mentioned that there's two big problems with wide area networks from a

0:44security perspective.

0:46One is the fact that it's unencrypted.

0:50Meaning I'm just sending my traffic into a shared service provider space.

0:55We know that.

0:56There we go.

0:59If I have an MPLS provider, for example, I am sending the traffic unencrypted

1:04into a shared

1:04space, but I'm also, keep in mind, sharing routes.

1:09This is interesting.

1:10This is something that I have to do with layer three providers and technologies

1:13, which includes

1:15MPLS.

1:16And I don't necessarily love sharing routes.

1:18That's a little bit of personal private information to my organization, and yet

1:23I have to share

1:24that with an entity in hope that nobody within that entity goes rogue and tries

1:28to capture

1:29my traffic or capture my routes.

1:32For that matter, that the service provider doesn't make an honest mistake and

1:35send my

1:36routes and traffic to another customer.

1:38So there's another check box.

1:40We also saw that routing complexity is a big problem with traditional networks

1:47or traditional

1:48wide area networks.

1:50And that especially is going to be true when we look at our redundancy.

1:56So having many routers, many service providers going to be a big problem.

2:01We also want to make sure that we have application considerations.

2:06So an application per circuit, especially as it relates to voice over IP

2:10traffic, for

2:11example, as well as bulk internet traffic.

2:14And then lastly, we have cost considerations.

2:17So we would definitely want to address that in some fashion.

2:21And yeah, SD-WAN might cost more than a traditional network because we're

2:26deploying additional

2:27services.

2:28But can we overall reduce the cost of our wide area network in some form?

2:33Because if so, then that would pay for the upgrade on its own.

2:37All right.

2:38So now we want to look at our software defined wide area network or SD-WAN

2:43solutions.

2:45And keep in mind, a lot of this is going to be a benefit that belongs to SD-WAN

2:51technologies

2:53even outside of the Cisco product world.

2:56So yes, this course and this exam is all based on Cisco, but Cisco is not the

3:01only provider

3:02of SD-WAN.

3:03This is not a Cisco only set of technologies.

3:06Now Cisco would argue, and probably most of us, in the Cisco world would argue

3:11that Cisco's

3:11solution is superior for a lot of different reasons.

3:14If not, then why are we here learning about it and why are we deploying it into

3:18our networks

3:19at all?

3:20But understand again, where some things make sense to call proprietary to Cisco

3:25, other

3:25solutions do exist in other forms with different vendors.

3:30So when I look at SD-WAN solutions, one of the big things we want to provide is

3:34what

3:35we call a single pane of glass management system.

3:39So single pane management.

3:42This takes the form, or ideally would take the form of me as an admin and

3:47potentially

3:48other admins as well, logging into what I said earlier, which is my wide area

3:56network

3:57from an interface perspective, meaning that my wide area network back here with

4:04all of

4:04the complexities of connecting all of the different sites is going to be

4:09entirely managed

4:10through this interface.

4:13This means that I have one place to go to log in and make changes to my wide

4:17area network.

4:18So this is going to allow me to perform configuration changes.

4:22It's also going to allow me to have that visibility to look and see what

4:27exactly is happening

4:29inside of my network.

4:31Now this is important because we might have an admin leave.

4:34Maybe it's our primary admin that decides to go on and take a new job somewhere

4:38, which

4:39is fine.

4:40That happens.

4:41It's part of life.

4:42Now these other admins have a much better chance of being able to log into a

4:47what would

4:47otherwise be a very complex solution and simply gain access to the environment

4:53in that way

4:54and 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

5:01of a graphical

5:02user interface.

5:03However, in our modern world, we also want to see that we have API access,

5:08which I'll

5:09allow for programmability of our software defined solution, which is pretty

5:14typical with any

5:14kind of software defined architecture.

5:17So we can check off the manageability and visibility box.

5:21We've already greatly simplified our wide area network space just by giving us

5:25that

5:26single pane of management.

5:28Now next, we also are going to build our architecture on IP sec tunnels.

5:35This is going to accomplish quite a bit for us.

5:37In fact, a very important part of this architecture that we're building out is

5:41the fact that it's

5:42built on IP sec tunnels.

5:45Now there's a lot to unpack here and we'll be unpacking this over the course of

5:48time.

5:49But what we do with IP sec tunnels and just tunnels in general is we're going

5:53to form

5:54the concept of an overlay and an underlay.

6:00I always like to say that the overlay is the network I want, but the underlay

6:07is the network

6:08that I have.

6:11Without building tunnels, what we have or what we have is what we have.

6:16I can't build something else on top of it.

6:18However, I can build tunnels on top of my existing physical architecture and

6:23then I

6:24can run routing protocols across those tunnels, which is pretty interesting.

6:28Here's what happens here is we see an underlay that consists of our service

6:34provider routers.

6:35Then the overlay, which is my routers up here and my whole network that exists

6:43maybe

6:43at my headquarters, maybe at my remote sites.

6:47The IP sec tunnel is going to allow me to send traffic through the tunnel

6:52across this

6:53physical infrastructure that I have.

6:56This would be the architecture that I have all of these routers, but what I

6:59really want

7:00is for this device on the left, this edge router to talk directly to this edge

7:04router

7:05on the right.

7:06Pretty fascinating how what happens when we build out these software defined

7:10architectures

7:10using overlay technology, in our case IP sec tunnels.

7:15What does this accomplish?

7:16Well, a number of things.

7:17Again, you said there's a lot to unpack here.

7:20First of all, let's address things from a security perspective.

7:23From a security perspective, we have just encrypted our traffic.

7:27That is huge.

7:28We said the unencrypted traffic is a problem and normally I would just bring a

7:31packet in

7:32to my edge router and send it to my service provider router without encrypting

7:38it.

7:38This is why the service provider we hope is not only honest, but also doesn't

7:43make any

7:43mistakes in terms of sending my traffic to the wrong customer.

7:48Because keep in mind that they do have other customers down here and they are

7:54fully capable

7:55of accidentally sending my traffic to the wrong customer, which might be some

7:59very sensitive

8:00information.

8:02The encrypted traffic is great because now it's using IP sec.

8:07But beyond that, I can also do direct routing.

8:12In a traditional MPLS network, again, if I'm handing my packet off with a

8:16destination

8:17of a network over here, well, in order for this router to send to this network,

8:22it needs

8:22to know where that network is, which is why I have to share routes.

8:25I have to tell this router, "Hey, I've got these private internal routes and if

8:31you see

8:31traffic for it, you need to send it to me."

8:34Well, that isn't required anymore because this router just needs to know how to

8:39get to

8:39the edge router, whichever one of these is technically the service provider

8:43edge in this

8:44scenario.

8:45That's all it has to know.

8:47Which means that I can bring traffic in and again from an overlay perspective,

8:52send it

8:52directly to the other side.

8:53Meanwhile, thanks to the power of encapsulation and tunnels, these underlay

8:58devices don't

8:59need to know anything more than their own network.

9:03So this is huge security.

9:04We've just checked that off from both perspectives.

9:06We're now encrypting our traffic and we're no longer sharing routes with our

9:09service provider.

9:12On top of that, our routing complexity, our routing environment has actually

9:18just gotten

9:19a whole lot better because, again, without having to share my routes, I don't

9:25have to

9:26do any route sharing anymore, and the ability for me to perform direct routing

9:32protocol

9:33adjacencies, this is huge.

9:35Remember the example we gave where we had external redistributed routes versus

9:40internal

9:40routes depending on the technology we chose.

9:43Well, now there is no redistribution required because I can run the same

9:49protocol everywhere.

9:51This massively simplifies my architecture.

9:55Furthermore, we mentioned that we want to control which applications use which

9:59circuit.

10:00Now, we can't go into the details of this until later on as we dig into the

10:05weeds, but

10:06what I can say is that because of this management pane, we have a whole lot

10:11more direct access

10:12as far as sending applications per circuit.

10:17So it's going to use the same concept as policy-based routing except it's

10:22managed.

10:23You and I, as an admin, we don't have to worry about forming very complex

10:28policy-based routing

10:29policies, which is very cool.

10:31So the routing complexity has been greatly simplified, both from something we

10:35can tell

10:36directly here as we have laid out using the same protocols everywhere, not

10:40having to

10:41redistribute, but also a little bit of trust-based teaching at this point that

10:46eventually we

10:47will see how the policy-based routing more or less is handled via the solution.

10:53Now, lastly, the cost.

10:54This is an interesting part of the conversation because, like we mentioned, SD-

11:00WAN hardware

11:00typically is going to cost more, not just because it's running different

11:05hardware, but

11:06also because there's going to be software costs, there's going to be licensing

11:10costs,

11:10it does require more cost.

11:12And yet, what we'll find is that we can actually overall reduce the cost.

11:16Now, this happens in a couple of different ways.

11:19First of all, when we lower complexity, this is going to naturally lead to cost

11:24savings,

11:25even 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

11:35working

11:35on things.

11:36Now, we're not saying we can go out there and start firing people, but what we

11:39are saying

11:40is we can redirect the team to other activities.

11:43We can be more efficient, and if we do our calculations correctly, we should be

11:49able

11:49to translate this efficiency into cost savings.

11:52Now the other way is a little bit more tangible.

11:56Remember those service providers that we talked about earlier, how MPLS

12:00typically involves

12:02a lot more reliability.

12:04Well, that's great and all, except it also comes at a much larger cost.

12:10So I might still deploy MPLS to one of these service providers, but now I don't

12:15need to

12:16worry nearly as much about making sure VoiceOver IP is taken care of.

12:20I can deploy the internet as a backup, swing my VoiceOver IP traffic down, and

12:26because

12:26routing is handled for me a little bit more, I can swing that traffic right

12:30back.

12:31So that's very important.

12:33But some organizations have even been able to remove MPLS and do dual internet

12:38circuits.

12:39This makes the wide area network enormously less expensive, and the reason we

12:43can do this

12:43is because we can always favor the more reliable, better performing internet

12:47circuit depending

12:49on the day.

12:50Now we want to be very careful.

12:52I am not saying that this is the right answer.

12:54In fact, very rarely it is the right answer, but it is something that is now

12:58technically

12:59possible.

13:00So we can build SD-WAN connections directly over internet circuits, regardless

13:05of whether

13:05it's in both locations or just in one, either way, that's a very tangible

13:10reduction in monthly

13:11recurring costs.

13:13So these are the ways that we have chosen to address the challenges of wide

13:18area networking

13:19and manageability, security, routing complexity, and yes, even cost overall can

13:26be seen as

13:27being 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

0:04Cisco

0:04Solution, which is simply known as Cisco SD-WAN.

0:09Cisco's SD-WAN product came after they developed their own product, which is

0:12known as I-WAN.

0:15And this was fairly short-lived.

0:16Cisco realized that other vendors already had pretty good solutions out there,

0:21and so

0:21they just decided to go purchase another company called Viptela.

0:26And 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

0:35naming perspective.

0:37But at the same time, at this point, it's been many, many years, and it really

0:41is now

0:41Cisco's SD-WAN solution.

0:44We're not going to expect to see much in the way of references to Viptela

0:48anymore.

0:49Now when we look at the Cisco SD-WAN solution, they divide their solution into

0:54four planes

0:54of operation.

0:56If we think about the networking side, we typically think about two primary

0:59planes with control

1:00and data plane, sometimes the management plane.

1:03And that's what we're going to see here, other than that Cisco is really trying

1:07to

1:07create its own architecture rather than trying to tie back to anything in the

1:11existing networking.

1:13That said, we certainly do have our data and control planes of operation.

1:19And specifically, data plane of operation, this is going to define the traffic

1:25paths.

1:25And as we'll see, this is where the IPsec tunnels are formed.

1:30We also have the control plane and the control plane defines the route

1:35propagation.

1:37And so far, this again feels like traditional networking, which is pretty good.

1:41Then we have the management plane of operation.

1:45And this is specifically going to tie back to that single interface, that

1:50single point

1:51of management, and this is going to be where we define how we manage things,

1:55whether through

1:56the graphical user interface or possibly APIs.

2:00Now lastly, this is the unique part of SD-WAN is that Cisco creates for us the

2:09orchestration

2:10plane.

2:13Orchestration is kind of an interesting one.

2:15We say, well, normally this isn't required.

2:17Why do we need this here compared to traditional networking?

2:21Well, because orchestration is going to help us with onboarding.

2:26We're talking about a software defined solution here.

2:29We're talking about hardware that needs to more or less create its own network

2:33on top

2:34of itself.

2:35But if I'm going to deploy a router out into the world, maybe a new remote site

2:41, how does

2:41it download all of this information?

2:44How does it even know to join the wide area network that belongs to my

2:47organization as

2:48opposed to other organizations?

2:50So that is the onboarding process.

2:52And we're going to require operation within this plane in order to bring

2:56everything online.

2:58So let's go into a little bit of details here.

3:01And we'll dive deeper and deeper as we go through the course.

3:04We'll look at the data plane of operation, our primary device that's going to

3:08participate

3:09in the data plane would be our edge devices.

3:13Now I'm using this word device.

3:16Cisco will use the word platform.

3:18Really these are routers.

3:20So always keep that in mind that we're primarily building this on Cisco router

3:25types of devices.

3:27From a legacy perspective, I always like to provide a little bit of context

3:31here.

3:32This used to be known as either a V edge or a C edge.

3:37Now Cisco has started to get rid of some of this terminology, but when we see

3:43this in

3:43documentation, it's going to be important for us to know what we're talking

3:46about.

3:47A V edge, that little V is in reference to Viptela.

3:51That means that we're deploying Viptela hardware.

3:54Now Cisco acquired Viptela as an SD-WAN provider and one that happened to make

3:58router hardware.

4:00Well as you might imagine, Cisco said, "Okay, that's great.

4:03On day one, we absolutely need to keep producing and selling and supporting V

4:07iptela hardware,

4:08but we're kind of known for making routers ourselves."

4:11And so once we get SD-WAN technology baked into iOSXE, our routing platform of

4:18choice

4:19for enterprise networks, then we're not going to continue to sell V edges

4:23anymore.

4:24And that's exactly what happened.

4:26So what Cisco did was they created an iOSXE flavor that can handle SD-WAN and

4:33they called

4:34that the C edge where now the C is short for Cisco.

4:38Well that's well and good other than again.

4:40We don't really sell V edges anymore and so Cisco got rid of the term C edge

4:45instead.

4:45We're primarily going to refer to this simply as, well actually let's do it

4:50like this, it's

4:50known as an SD-WAN edge device.

4:56And we're going to see that a lot of our older nomenclature or older titles

5:02have been replaced

5:03by something that sort of follows this format.

5:06So what exactly is this data plane all about?

5:09Well again, we're typically going to run these in the modern network on

5:13catalyst 8000

5:14routers.

5:15Cisco calls these edge platforms, but either way the catalyst 8000s is what we

5:20're typically

5:20going to run on SD-WAN on, although we could run this also on integrated

5:26services routers

5:27and aggregation services routers and we'll talk about the details of that

5:31coming up.

5:32But interestingly this can be physical or it can actually be virtual.

5:38So we could deploy cloud routers into cloud spaces and allow them to

5:43participate by building

5:44out those IP sec tunnels.

5:46Very cool and we're going to leverage this virtual concept especially for

5:51creating labs.

5:53But keep in mind in the real world we can deploy these into cloud spaces as

5:57well.

5:58So 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.

6:09The IP sec tunnels operate inside of the data plane.

6:13So when we're looking at our SD-WAN edge here as well as the IP sec tunnels

6:19these are facets

6:21of the data plane.

6:23Now as we go through these we can now look at the non data planes of operation

6:28including

6:28the control plane.

6:31So the control plane is going to run not as a router but this is going to be

6:36deployed

6:37as a virtual machine.

6:39Meaning I might deploy this into my own data center or into a cloud space but

6:42either way

6:43the control device of choice is going to be a virtual machine and that device

6:49is known

6:50as the SD-WAN controller.

6:54Now if you've studied SD-WAN before you probably weren't expecting me to say SD

6:57-WAN controller

6:58but again Cisco has rebranded things.

7:02This used to be known as the V smart.

7:06Where the little V is once again part of that Viptela acquisition but Cisco

7:10left this alone

7:11for a very long time.

7:12It's only really recently that they started to call things by different names.

7:16So it used to be the V smart now it's the SD-WAN controller and this is going

7:21to be

7:22responsible for route propagation.

7:27Now when we talk about route propagation we're not talking about OSPF or EIGRP

7:34we're primarily

7:35talking about OMP here.

7:37We're going to be using the overlay management protocol which is going to allow

7:41us to propagate

7:42SD-WAN control information to all of the devices.

7:46From here we can talk about the management plane and the management plane once

7:53again

7:53is going to have well first of all we deploy this as a virtual machine into our

7:59network

7:59and this is known as the SD-WAN manager.

8:06So far the names make sense.

8:08Managers part of management plane of operation the controller is part of the

8:13control plane

8:13of operation and nothing too complex here but just wait a moment until we get

8:18to the

8:18orchestration plane but either way the SD-WAN manager also had a name that we

8:23used to call

8:24this which is V-Manage.

8:28And again Cisco only recently made that change.

8:30There's a whole lot of documentation and software references to be managed we

8:35do need

8:36to know both names in all of these cases.

8:39So the idea here is that once again we'll log in either via graphical user

8:43interface

8:44or API and importantly it's a single way for us to manage the entire SD-WAN

8:51environment.

8:54However as you can imagine we'll want to deploy a pair of these for the sake of

8:59redundancy.

8:59Now lastly this is the one I was joking about.

9:03Now we have to worry about the orchestration plane and this is going to be

9:08known as an

9:09SD-WAN validator.

9:12Oh yeah where did that name come from?

9:15Well Cisco decided to come up with it apparently and that's perfectly fine.

9:19This used to be known as a V-Bond and the idea with calling it the V-Bond is

9:26that it

9:26was 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

9:37the

9:37device is supposed to be on our network and the device needs to make sure it's

9:40attaching

9:40to the same network or the correct network and so yeah there's some validating

9:44that happens

9:45during this process but just keep in mind if we see SD-WAN validator this doesn

9:51't tie

9:51to a validation plane operation it's going to map to the orchestration plane of

9:57operation.

9:58So from here again the main thing we're focusing on I won't write it again it's

10:03the fact that

10:04we're trying to onboard our devices and this is actually the first point of

10:08authentication

10:09as well.

10:10So as I keep saying we need to make sure that this device attaches to the

10:14correct network

10:15and we as the network don't want random devices attaching to us and becoming

10:19part of our

10:20wide area network security must be baked into the solution from the ground up

10:25and fortunately

10:26it is.

10:27So I highly recommend coming out of this conversation that we have a good sense

10:31of which devices

10:33belong to which planes of operation and I would highly recommend also knowing

10:39the old

10:39names the V-Bond the V-Manage the V-Smart as well as the V-Edge and the C-Edge

10:44concepts.

0:00All right, we are going to end this skill with a challenge.

0:03In fact, we're going to find that we end every single skill with a challenge.

0:07I highly recommend taking the time to do every single challenge.

0:10It's going to help us to reinforce the knowledge that we've learned.

0:13Sometimes it will be something like an interactive quiz like this, interactive

0:16being that we'll

0:16explain the answer afterwards.

0:19We might be a lab, we have to create a lab topology and perform configuration.

0:23It could be anything.

0:25But the idea here, generally speaking, is that we want to again reinforce what

0:28we've

0:28learned 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.

0:35I encourage you to pause the video.

0:36I'm not going to leave a whole lot of time to answer it.

0:38So pause the video, make sure you can answer it yourself, and then unpause the

0:43video.

0:43And again, we'll go through the answer.

0:46So first up, out of three questions here, what is the tunneling mechanism used

0:50in the Cisco SD-WAN

0:52solution?

0:54Tunneling is a major part of the SD-WAN solution.

0:57We're going to have the underlay.

0:59That would be the service provider network.

1:01And then we're going to build an overlay on top of this.

1:05And this overlay is going to be built with IPsec tunnels.

1:09This is very important.

1:10IPsec is what we're going to be using.

1:12We're not using VXLAN, which is a layer two tunneling mechanism.

1:16And what we'll find is we can actually use GRE.

1:19That actually is an option, but it's not one we're going to often deploy

1:23because

1:24it doesn't give us security.

1:26And that is one of our primary concerns here.

1:28And 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?

1:39Well, if you're like me, you love, or at least enjoy somewhat, logging in via

1:46the CLI to a network

1:48device.

1:48And we know that our wide area networks might have a lot of devices.

1:53This doesn't scale.

1:54It's a problem that exists with our modern networks.

1:56And so we're not going to rely on this.

1:58Instead, what we're going to do is we're going to insert a middle software

2:03package that then

2:04pushes configurations via APIs.

2:07And so the idea here is we will be logging in to a software package that we now

2:14know

2:14is known as the SD-WAN manager, formerly known as VManage.

2:21And furthermore, we can use graphical user interface, or we could actually

2:26leverage APIs

2:27in order to access the software.

2:28There will be CLI commands that we can use to log in and troubleshoot, but that

2:33's not going to be

2:33our primary mechanism for managing the overall solution.

2:37Instead, 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

2:46manageability of all of the nodes in our software defined wide area network.

2:50All right, question number three, and it is the last one.

2:55Which Cisco SD-WAN device helps with the onboarding process for new devices?

3:00Well, the answer here is going to be D, the SD-WAN validator, which is part of

3:04that orchestration

3:06plane. This used to be known as the V-bond.

3:09And the idea here is that as new devices come online, we've got to find the

3:14rest of the network

3:15way over here. And so it's going to reach out to the V-bond and the V-bond will

3:20connect

3:21this device to the proper network.

3:24Now it is important, as we've said, that we know which plane of operation each

3:29one of

3:29these devices operates within. There's four planes and four devices, so it

3:33matches up well.

3:34And furthermore, I'd recommend knowing the legacy names like V-bond.

3:38So as we go through these, the edge used to be known as the V-edge for the Vipt

3:42ela hardware,

3:43the C-edge running iOSXe. And this belongs in the data plane.

3:48The SD-WAN controller used to be known as V-Smart. And as the name implies,

3:53this is part of the

3:54control plane. And lastly, the SD-WAN manager used to be known as V-Manage. And

3:59that's part of the

4:00management plane of operation. So as we get to the end of a quiz like this,

4:06what I would recommend

4:07is using this as a guide to let us know, are there any gaps in our knowledge

4:11that we should go back

4:12and shore up before moving on? So for example, we don't maybe know all four of

4:17the planes of operation

4:19or this made us aware that we don't quite have the legacy names memorized. We

4:23should go back and

4:24review that content as well as any other content that we feel like we need to

4:28know better before

4:29moving on to the next skill. I hope this has been informative for you and I'd

4:32like to thank you for