Review Software Defined Architectures

0:00It's always tempting to want to just move on to the next subject, but we've

0:04just covered

0:04some really big ones.

0:06Software-defined weigh-in, software-defined access, these are massive new

0:10technologies,

0:11relatively new technologies, because at this point they've been around for

0:13quite a few

0:14years, but in the grand scheme of things, routing and switching didn't change a

0:17whole

0:17lot for a long time.

0:19And then all of a sudden we get software-defined infrastructure, so SD access

0:22completely changes

0:23the way we deploy access layer, switching, and software-defined win completely

0:27changes

0:28the way we deploy our wide area networks.

0:31And so before we move on, let's go ahead and take a moment to pause, hit the

0:36brakes,

0:37take a breath, and remember everything that we've been learning, because there

0:42was a lot

0:42of information.

0:43It was hard for me to pack all of that information we talked about into a

0:49decent summary, because

0:50there was just so much.

0:52So let's be sure to take a few moments here to remember what we've learned to

0:55lock it

0:56in for the future, and hey, bookmark this skill as well, because later on when

1:01you're

1:01preparing to maybe go take the exam, rather than going back through every

1:05single skill,

1:06maybe we can target some of these review skills, say let's just go through that

1:10.

1:10And the goal here is obviously number one, we want to answer the questions and

1:13get them

1:14right, but don't be discouraged by getting the answers wrong either, because

1:19what that

1:19allows us to do is say, "Hey, I need to work on that."

1:22It helps us to identify our areas of weakness.

1:25Not one of us has all of this memorized and all of this down, so when we're

1:29going through

1:30this, make sure to flag any questions, say, "Hey, I need to learn more about

1:33that or remember

1:34more about that."

1:35I can go back to the skill that's referenced in the quizzes and make sure that

1:41I can answer

1:42that question moving forward.

1:44So as far as the format's concerned, we're going to do some quiz questions, we

1:47're going

1:47to do some challenges, but let's go and dive into this review.

0:00Well, the format for these quizzes is going to be what we've done several times

0:04up until

0:05now, which is to ask some quiz questions, but I'm not going to pause the video

0:09and give

0:09a lengthy silence.

0:11What I'd encourage you to do is once we get done reading the quiz question, you

0:15hit the

0:15pause button and make sure you can answer it yourself before unpause it and

0:20watching

0:20the solution in order to verify.

0:23So for example, with this question here, what are the four planes of operation

0:26for Cisco

0:27SD-WAN?

0:28This is an open ended question.

0:29So again, hit the pause button, maybe grab a piece of paper and a pad of paper,

0:35a piece

0:35of paper and a pencil, whatever you need to write stuff down and make sure that

0:39you can

0:39answer this question yourself before again, we start to talk about the solution

0:45.

0:45So what is the solution here?

0:47Well, Cisco's SD-WAN architecture is pretty sophisticated and it doesn't

0:52involve these

0:53four planes of operation.

0:55We might be used to control plane and data plane when we're talking about

0:59normal network

1:00operations.

1:01And certainly that's going to be the first two.

1:03We're going to have a control plane of operation, which allows us to share

1:07routes with one another,

1:09make sure we know how to encapsulate our traffic and get it to the destination.

1:14We have the data plane, which involves building those secure tunnels and

1:17allowing us to send

1:18traffic from one WAN device to another WAN device.

1:22But there are a couple others here as well.

1:24First of all, we have a management plane of operation.

1:27This is how we manage the entire SD-WAN infrastructure from that single pane of

1:32glass is a huge part

1:34of software defined infrastructure is getting us away from piecemealing

1:38everything, configuring

1:40dozens of devices to try to work in concert and orchestration with one another.

1:46Instead, we simply log into one interface, one device and tell the network how

1:52we want

1:52it to run and it pushes that configuration everywhere.

1:55It has an immense benefit to software defined architectures.

2:00The last plane of operation is that orchestration plane.

2:04This is especially focused on onboarding.

2:06We want to be able to streamline our ability to spin up new software defined W

2:11AN, especially

2:12those WAN edge devices and the orchestration plane is going to help with the

2:16onboarding

2:17process, help with dealing with our NAT, bypass and such.

2:21And so all four of these planes of operation are mission critical for SD-WAN

2:27operation.

2:28Question number two, match the SD-WAN device to its plane of operation.

2:33So we just talked about the four different planes.

2:36And what we find is that there's one device that belongs to each one of those

2:40planes of

2:41operation.

2:42So which one is which here?

2:43Well the SD-WAN edge devices would be the device that's actually sitting here

2:48at the edge

2:49of our network, of our wide area network specifically.

2:52And so usually this is our layer three router type of device that's going to

2:57communicate

2:58into the site.

3:00And then it will have ideally a handful of wide area networking circuits back

3:05up into

3:06the network.

3:07So this is going to be responsible for sending traffic from one edge device to

3:13another edge

3:14device, which will communicate with another site.

3:17Maybe this is the headquarters.

3:19But either way, this device at the edge, this is part of our data plane of

3:24operations.

3:26So the V-Manage.

3:27The V-Manage is going to be our management plane as the name implies.

3:32So this is where I as an admin once again need that single pane of glass.

3:39I'm going to log into V-Manage and it's going to push configuration everywhere.

3:43The V-Smart, this is the control plane device.

3:48So my V-Smart are going to receive routes and routing information and it's

3:53going to push

3:54it down to the other WAN edge devices.

3:59And then the V-Bond, this is part of that orchestration plane.

4:03And it's going to help me again with onboarding and that bypass.

4:06So the V-Bond has to be out here with a public IP address.

4:10It has to be reachable and fully accessible because again of that net bypass

4:17part of the

4:18operation.

4:19So these are the four devices.

4:21Also keep in mind, that Cisco has started to come up with new names for all of

4:25these

4:26devices.

4:27In fact, the edge device used to be known as the V-Edge and also the C-Edge as

4:32we talked

4:32about.

4:33So we're no longer calling the V-Edge.

4:35Well, Cisco started to migrate all of these as well.

4:38So when it comes to the V-Manage, we're talking about the SD WAN manager.

4:44With the V-Smart, we're talking about the controller, which fits pretty well

4:49with the

4:50control plane of operations.

4:52And then this is kind of the tricky one, orchestration plane, instead of

4:55calling it

4:56the V-Bond, they are now calling it the validator.

5:00So let's start to keep these new terms in mind as well as we learn the

5:05architecture and start

5:07to get our hands on it.

5:09It's going to depend on which Cisco documentation we're looking at, whether it

5:13's calling it

5:14the old names or the new names.

5:16And so that's why it's going to be important that we know both.

5:20Question number three, what type of tunnels are used for the SD WAN data plane?

5:25So the data plane is going to use secure tunnels that communicate between our

5:31SD WAN edge devices.

5:32And so those secure tunnels are going to be formed using IPsec.

5:37So keep that in mind that when we've got our devices at the edge here, we've

5:42got lots of

5:43physical circuits and physical paths to one another.

5:48But one of the ways that SD WAN simplifies everything is by building tunnels.

5:53So I'm going to build, for example, an IPsec tunnel here across one WAN circuit

5:59over here

5:59as well with another WAN circuit or across the other WAN circuit.

6:03If they happen to both use the internet, we might see a full mesh of tunnels

6:07forming.

6:08But either way, these data plane tunnels are using IPsec.

6:11So when a packet shows up on this router, it needs to go over to this other

6:14site, it's

6:15going to ride one of those IPsec tunnels to the other side.

6:19That's what we mean by data plane operation.

6:22And it's very important that we're using IPsec because a huge part of what we

6:25're trying

6:25to accomplish with SD WAN is not only simplifying our traffic flow and giving

6:30us more control

6:31over it, but also adding a layer of security, whether that's because we're

6:35riding over

6:36the internet or because we're using a service provider technology like MPLS

6:41that would be

6:42shared with other organizations.

6:46And question four, what does a VPN represent in Cisco's SD WAN architecture?

6:52This one might be a little bit tricky because VPN, as we've said, this usually

6:55means something

6:56different, especially when we're already talking about IPsec tunnels.

7:01But within SD WAN architecture, the VPN is sort of like a VRF, which we'll be

7:05talking

7:06about in more detail coming up soon.

7:08But a VRF is essentially just a completely different routed domain.

7:13And so the answer here is going to be D. It's a segmented routing domain.

7:16And the primary reason we have this is for the sake of multi-tenancy.

7:21SD WAN is a technology that regularly gets deployed by service providers, and

7:26they sort

7:27of sell the solution and manage it.

7:30But the customer doesn't get to interface with it.

7:33We, as the service provider, are managing a multi-tenant environment, and

7:36therefore every

7:37customer is going to get their own VPN.

7:42That's why it's called a virtual private network, even though from a strict

7:45routing and switching

7:46perspective, it really is closer to a VRF.

7:50And so we need to think of it from both perspectives there.

7:53But either way, it is a segmented routing domain, and it's going to allow us to

7:57build

7:58things out securely if we do have multiple customers.

8:01If we're an enterprise customer, we're probably going to have just one VPN in

8:06most situations

8:08outside of some of the other VPNs that are used for management.

8:11But if we have a use case for deploying multiple VPNs, then we can certainly

8:16take advantage

8:17of that as well.

8:18All right, question number five.

8:21We're halfway done, by the way.

8:22I didn't say it at the start, but we have eight questions.

8:25So we've answered four of them, four more to go, starting here with question

8:28number five.

8:29So what is the full VPN range in Cisco SD WAN and how are VPNs zero and 512

8:36used?

8:37Well, the full range here originally actually was zero to 512, which is kind of

8:43interesting

8:44because, yeah, 512 is a binary number, but it goes one past the value.

8:50Like if we were actually using nine bits, then we would have zero to five 11.

8:55So we know we have more bits there.

8:56It's just the Cisco and Viptela, especially originally, we're restricting it.

9:01The full range, at least at the time of this video is up to 65,530.

9:07Yeah, not three or five 35 like we might expect, which is again, is another

9:12binary number.

9:14Those last five must be reserved by Cisco for some reason at this point.

9:18But either way, that's the full range.

9:20However, two of those values, zero and 512 are reserved.

9:26And the reason why is zero and 512 of all these numbers comes back to the fact

9:30that it

9:30used to be zero to 512 was allowed with the first and last being reserved.

9:35So our usable range actually is from one to five 11.

9:40And then we have to put a break here and say five 13 to 65,530.

9:46So this is the usable range of VPN IDs and zero and 512.

9:52Again, our reserve.

9:53So what are they reserved for?

9:54Well, VPN zero, this is going to be reserved for the actual WAN circuits, which

10:00is the

10:00ultimately saying this is the underlay.

10:02Again, this is a completely segmented isolated routing environment.

10:09And what we're trying to create here is the idea that whatever this underlay

10:13looks like

10:14with multiple routers in the path that I'm just forming this tunnel and

10:20allowing my routes

10:22to flow over this tunnel.

10:24And I don't need to know these routes in the overlay and the underlay doesn't

10:29need to

10:30know the overlay routes.

10:32So we're creating this.

10:34Draw it like this here.

10:35We're creating these two different routing domains.

10:37We're creating the underlay here and we're creating the overlay up here.

10:41And generally speaking, we don't want those routes to mix, which is why we have

10:45again,

10:46if we think about VPNs as VRFs, that's why we have our YN circuits listed and

10:52dedicated

10:53as a as VPN zero.

10:55Now we also have VPN 512.

10:58This is used for out of band management.

11:01And so this is really helpful and useful for organizations that like to isolate

11:06their

11:06management and keep that in a dedicated route and domain.

11:10But as far as our actual usable VPNs for our data traffic, we're going to have

11:17to pick

11:17one of these VPNs.

11:18Again, if we're an enterprise shop, we're probably just going to pick one of

11:21these.

11:22If we're a service provider, then we're going to use a whole lot of them

11:24because every customer

11:25is going to get their own.

11:28Question number six, it's about T locks here.

11:30So what are the three components of a T lock, a transport locator?

11:35So the T locks are interesting because the T lock essentially defines a path to

11:41a router

11:42or really a WAN edge device.

11:45And yet it doesn't actually tell us how to get there.

11:48Kind of curious.

11:49We're going to need to rely on OMP to say, Hey, if you're trying to get to this

11:53T lock,

11:53go to this address.

11:55So what's the purpose of the T lock?

11:58Well, the T lock is used for making decisions.

12:00And I need to make decisions based on this three tuple set of data that's being

12:05presented

12:06by the WAN edge device, sort of describing itself and describing these

12:11different paths.

12:12So we can think of them as paths and how would we describe paths?

12:16Well, first of all, we're going to include the system IP here.

12:20So the system IP is again, not a routable or necessarily a routable IP address.

12:27It's just simply an identifier to say, Hey, this is me.

12:31And I'm going to use the same system IP across different T locks.

12:33If I have different paths, the second part of the tuple is going to be the

12:38concept of

12:39the color.

12:40The color is essentially trying to say that this is part of a particular wide

12:46area network

12:47domain.

12:48So we've mentioned that a WAN edge device likely has at least a couple of upl

12:53ink circuits,

12:55especially if we're deploying SD WAN, if we just have a single uplink circuit,

12:59SD WAN

12:59isn't going to bring us a whole lot of value.

13:02So it's usually going to be seen that we're deploying SD WAN when we have

13:05multiple circuits,

13:07we might even have three or four circuits at some critical sites.

13:11Well, this creates three different service provider paths.

13:15And as part of the T lock, I want you to know that, Hey, if you're trying to

13:17come in on

13:18this path, you're going to use this particular service provider.

13:23So the color remember is a string.

13:26And for better or worse, we can't define that ourselves, but Cisco gives us a

13:30lot of options.

13:31And we can use things like red and green or gold and silver.

13:35And there's all kinds of other ones as well, even descriptors like MPLS.

13:40But this color is going to tell us about how I can approach and use this T lock

13:46.

13:46The last thing we need is the encapsulation.

13:49So the encapsulation is going to tell me what I'm using, whether it's IP sec or

13:55GRE.

13:56But we just got done saying that IP sec is used at the data plane.

14:02And in every SD WAN deployment, this should be the case.

14:05Outside of maybe a lab environment, I suppose.

14:09But we do have GRE as an option.

14:11GRE is essentially just saying, Hey, we're going to use an unsecured tunnel

14:15rather than

14:16relying on the security of IP sec.

14:19There might be some really niche type of situations or corner case scenarios

14:23where we

14:24can't encrypt our traffic for one reason or another.

14:27Maybe it has to do with the country of operation.

14:30But generally speaking, we're going to be using IP sec.

14:33As I have said, keep in mind GRE is technically an option.

14:37And as a result, it's going to have to be included in the T lock.

14:40So the T lock again consists of three components.

14:43It's the system IP.

14:44It's the color and it's the encapsulation that can include in the T lock.

14:48And remember, these don't by themselves tell us how to route and get here.

14:54We're going to need OMP to glue that part together later.

14:59Question seven, which SD WAN device serves as an OMP route reflector among the

15:05WAN edges?

15:06Well, the answer here is just straight up the V smart, otherwise known as the

15:12SD WAN

15:12controller, I suppose with modern terms.

15:15But either way, this V smart is going to serve as a route reflector.

15:19What do we mean by route reflector?

15:21And why did I use quotes here to describe it?

15:24Well, it's because route reflector is actually a BGP term.

15:28But as we've said a few times, OMP is very BGP like in its behavior.

15:34One of the ways that's BGP like is that it can perform its operations as a

15:39route reflector.

15:41Because unlike with our other routing protocols that use multicast, we're not

15:45just forming

15:46relationships with everybody.

15:47We can kind of choose who we form relationships with.

15:50And so I might have multiple WAN edge devices here.

15:54And I want to share a route into this space.

16:00Well, if I'm not using intelligence here, as far like trying to make it a

16:05little more

16:06efficient, I might have many, many, many WAN edges here.

16:11And if I was not going to use a route reflector or anything other, again, more

16:16efficient,

16:16I'd have to share this with every single other WAN edge device so they know how

16:21to get to

16:22this route.

16:23Well, fortunately, I don't have to worry about that.

16:25I don't have to maintain a full mesh of adjacencies, which as we can imagine,

16:30as this grows out,

16:31it would become very unsustainable for us to have that many OMP adjacencies or

16:36whatever

16:36routing protocol we're using at that point.

16:39Instead, the V smarts going to serve as a route reflector, which means I

16:42advertise it

16:43one time to the V smart and it's responsible for pushing it down to all of the

16:49other WAN

16:50edge devices.

16:51So the V smart is a very important part of this.

16:54OMP is a very important part of this.

16:56And in this case, our focus is just simply trying to say, "Hey, I've got this

17:00route subnet

17:01A I want you all to know about."

17:03And the V smart helps me get the word out to the rest of the WAN edges that

17:07route A lives

17:09on my port.

17:10All right, question number eight, the last question, which six parameters are

17:15used to

17:16identify a traffic flow for application aware routing when DPI isn't in use?

17:22Cisco's deep packet inspection or DPI is really great for identifying traffic

17:27types.

17:28And this is important because as part of deploying SD WAN, I can look at

17:35traffic coming

17:36in and identify the traffic.

17:40And depending on the traffic type, I might want to send some traffic one way

17:44and some

17:44traffic another way.

17:45For example, I might want to send my bulk traffic across an internet circuit,

17:49but my

17:49voiceover IP traffic should go out towards MPLS, something along those lines.

17:55So the question is, how do I identify the traffic?

18:00And deep packet inspection is a great way to do it, but as we recall, it does

18:04require

18:04an additional license.

18:06And we make sure we have the right hardware in place and all of that.

18:10So we have a backup plan, which is to use the six tuple.

18:14We talked about the three tuple, tuple earlier with T locks.

18:18Now we're talking about the six tuple.

18:19So we're simply going to equate a flow to the six tuple.

18:25If we share these six pieces of information, then we are part of the same

18:29traffic flow.

18:31And so that's how we're going to identify our traffic.

18:33So how do we do this?

18:34Well, we're going to take a look at the six different, six different, I guess,

18:40identifiers.

18:42We have to look through each one of these.

18:44So first of all, we're going to look at the IP address for source and

18:47destination.

18:47So that would be two of them.

18:49We're not going to look at the MAC addresses because MAC addresses can be

18:52deceptive.

18:53If we're routing between two different routers, well, the source of destination

18:58MAC address,

18:59those are brand new.

19:00They're just for those routers.

19:01It doesn't tell us what actually is communicating.

19:04So we don't want to rely on MAC addresses.

19:06IP addresses are persistent end to end.

19:09So would be the source and destination port.

19:11That's another two of our six.

19:12So we're up to four so far.

19:15And then we're also going to take a look at DSCP and protocol number.

19:20So these would be our six points of identifications.

19:22It's going to allow us to identify traffic as it comes into the router, make

19:26sure that's

19:27going out the appropriate up link when we're using application aware routing.

19:31So that ends the quiz for SDWAN.

19:34Let's go ahead and jump into a challenge to make sure that we fully grasp how

19:38the architecture

19:38comes together.

0:00All right, let's draw some tunnels here on this diagram.

0:03So we're talking about the TLS and DTLS tunnel for non-data plane traffic.

0:08We're really talking about seeing these tunnels establish among all of the

0:13different devices

0:14for the most part.

0:15And so we're going to see, for example, our edges form TLS or DTLS tunnels to

0:23the V smart

0:24and same thing over to the V manage.

0:27But one thing to keep in mind is that even though we do form DTLS connections

0:31to the

0:32V bond, which only supports DTLS, as we recall, those actually get broken down.

0:38So we start by forming these tunnels, but then they do end up going away.

0:43Meanwhile, we do maintain a full mesh of TLS or DTLS connections among the

0:50different non-data

0:51plane nodes as well.

0:53So quite a few of these TLS or DTLS tunnels in our environment.

0:58So let's now talk about the IPsect tunnels.

1:02So the IPsect tunnels are going to be used for data plane traffic, and those

1:05are only

1:06going to be maintained among the edge devices.

1:11Now these IPsect tunnels usually are going to end up being built in a full mesh

1:15fashion

1:16across different WAN fabrics.

1:19So if we have multiple WAN fabrics, then we need to figure out, okay, well,

1:23maybe I form tunnels through this one as well as through this one in order to

1:28get to the

1:29same WAN edge device.

1:31For now, we're just going to show this as a full mesh among the edge devices,

1:34but do

1:34keep in mind as well that we have partial mesh options.

1:39So it's not so much that it has to be full mesh.

1:42We could do partial mesh.

1:43We have control over that, but in a lot of situations, we're forming a lot of

1:47IPsect

1:47tunnels among our edge devices.

1:50Now lastly is the OMP route exchanges.

1:53As we talked about in the quiz, if I am exchanging routes with the V smart as a

1:58edge device,

1:59well, those routes will get pushed down from the V smart to the other edge

2:04devices thanks

2:06to the fact that it's going to serve as a sort of a route reflector.

2:10So I don't need to share routes directly with other edge devices, and we don't

2:15need

2:15to share routes outside of the V smarts.

2:18So that's how a lot of these connections come together.

2:22Let's just try to remember how the different tunnels are formed and what those

2:25look like

2:26and which devices are forming those tunnels.

0:00All right, it's time to jump into software defined access.

0:03So SDA is all about giving us a method for deploying a campus fabric.

0:08Campus fabric is going to be a new way of deploying our access layer.

0:12So we don't have to choose between layer two and layer three.

0:15So once again, pause the questions before we get into the answers in order to

0:19take a

0:20crack at it yourself.

0:21So question number one here, and there's eight questions this time as well.

0:25What are two goals for deploying campus fabrics?

0:27Well, what we're trying to do once again is evaluate layer two versus layer

0:32three to the

0:34access layer.

0:35And both of these have pain points.

0:37Layer two is flexible, but it has spanning tree protocol.

0:41Layer three has an immense amount of scale, but we lack the flexibility.

0:47And so we want to try to find the best of both worlds.

0:50And this leads us to the campus fabric.

0:54The idea of the campus fabric is I will build a layer three underlay.

0:58So we're basically embracing layer three to the access.

1:02So our switches all communicate via layer three to one another.

1:07But we're going to build tunnels that allow us to still connect at layer two.

1:12We've got this concept where yeah, I'm layer three segmented, but I've got

1:17hosts over here.

1:18I've got hosts over here and they're all part of the same subnet, whatever that

1:25is pretty

1:25fascinating and really neat.

1:27And what this allows us to do is first of all, hey, eliminate spanning tree.

1:31One of the best things you can ever tell a network engineer is we'd never have

1:35to deal

1:35with spanning tree ever again, because our architecture is fully layer three.

1:40We're not going to eliminate routing.

1:41We're actually going to deploy routing some kind of routing protocol under the

1:45hood there.

1:47And the other goal here is to maintain our layer two networks.

1:51We're not looking to remove them.

1:53So in that sense, we're also embracing the layer two side of things.

1:56I mean, I really can't describe any better.

1:58It's a best of both worlds approach.

2:00We don't have to worry about the pain points for either one, but we get the

2:04benefits of

2:05each one.

2:06It's pretty fascinating.

2:07Now security is not an inherent part of deploying campus fabrics.

2:13It is an inherent part of SDA.

2:15It's go baked security into SDA from the ground up.

2:19But for this question, we're specifically talking about campus fabrics

2:22independent of

2:23SD access.

2:25Question two, what are the four layers of the Cisco SD access solution?

2:30So we talked about the four layers for SD when now we're talking about the four

2:35layers

2:36of SD access.

2:38So the four different layers are going to be very different this time.

2:43It's going to involve the physical layer, the network layer, the controller

2:52layer, and

2:52the management layer.

2:56Now we're not going to dive too deep into any one of these, but as a very quick

2:59overview,

3:00remember, a physical layer involves the different devices that are going to be

3:05at play here.

3:06We've got specific devices, catalyst nine case, for example, that we're going

3:10to want

3:10to deploy into the physical layer side of the network.

3:14We're going to also, by the way, keep in mind, we've got wireless devices like

3:18wireless

3:19land controllers in there as well.

3:21The network is where things start to get a little bit interesting.

3:23We've got those three different components we're going to be talking about here

3:27that

3:27allow us to build out our fabrics.

3:30And so I won't spoil it because we're going to ask questions about it coming up

3:33.

3:34But if you do recall those three different protocols that are very important as

3:37part

3:37of the network layer.

3:39The controller is going to consist of our two controllers.

3:44First of all, our primary one, what used to be known as DNA center or D-NAC is

3:49now known

3:50as catalyst center.

3:51And then we've also got ICE for identity services engine and identity

3:56management.

3:57And then management layer itself, this is going to be where we have a graphical

4:01user

4:01interface in order for us to manage the environment.

4:04But we've also got REST APIs.

4:06And we can be very programmatic in our approach to deploying software defined

4:10access.

4:11So let's remember these four different layers.

4:13They're very different from SD-WAN.

4:15We need to make sure that we're keeping all of these layers straight in our

4:18minds.

4:18All right, I said I wasn't going to spoil it.

4:22And so now we're going to talk about those protocols.

4:24So match the protocol to the plane of operation within the SD access network

4:29layer.

4:30So now we've got layers and we've got planes.

4:32What's going on here?

4:33Well, when we're talking about planes of operation, we're talking about the

4:37data plane, control

4:38plane and policy plane.

4:39This sounds a little closer to those planes of operation, the layers, whatever

4:43we want

4:43to call them in SD-WAN.

4:46Within SD access, we're going to take that network layer and we're going to

4:51split it

4:51up into different planes.

4:55And specifically these planes of operation.

4:58So this is a layer.

5:00These are planes.

5:01Once again, we have to keep in mind which one is which, but the planes fit into

5:06the layer.

5:07Now the data plane, this is where we're going to, again, we've got to identify

5:11the protocols

5:12we're using at the data plane, we're forming tunnels.

5:15We saw on SD-WAN, we're using IPsec tunnels, but that won't work with SD access

5:20where we

5:21need a layer two.

5:22So we're going to rely on a different mechanism that gives us layer two and

5:26that is the X-LAN.

5:28We'll be diving into VX-LAN in more detail coming up here.

5:32And by the way, we'll be diving into something else in more detail coming up,

5:35which is the

5:36control plane protocol known as LISP, which changes the way we share routes.

5:41We don't push routes everywhere just in case anymore.

5:44We just pull them in on an as needed basis and the policy plane is going to use

5:49Cisco

5:49trussec.

5:50Cisco trussec is going to include a security tag, something called a scalable

5:55group tag

5:55used to be called security group tags, either way, they're SGTs.

6:00And that allows switches to know, hey, is this device allowed to talk to

6:04another device?

6:05It really helps us out with onboarding devices and generally speaking access

6:13control.

6:13Question four, identify the SD access device type that's responsible for each

6:17of these

6:18operations.

6:19We need to go through all four of these.

6:21So what device type, first of all, what are we talking about with the device

6:24types?

6:25Well, I'm thinking about things like the control plane nodes, we're thinking

6:28about the border

6:29nodes.

6:30Some of these guys, we've got the just simply the fabric edge nodes.

6:37These are a big one.

6:39And then out of all of these, we might also be concerned about fabric wireless

6:43and controllers.

6:44So we'll look at gateway access to non-SDA networks.

6:49When we're talking about non-SDA, we're talking about the external world.

6:53We've got a fabric here.

6:55We've got all of these switches.

6:58These are all access closets.

6:59At some point, we're going to need to get out to the network core to route out

7:03to other

7:04networks.

7:05Maybe that's the internet.

7:06Maybe that's the data center, wherever we're going.

7:09Well, that's going to be the responsibility of the fabric border node.

7:13And yes, Cisco does like to include the word fabric and we should probably

7:16include it as

7:17well.

7:18So we have a fabric border node that sits here and we're going to send traffic

7:23to the border

7:24node with either the border node telling us, hey, I've got a route to the data

7:28center,

7:29or simply put, I don't think that we know where this destination is.

7:33So I'm going to forward it to the border node, hoping it's destined out towards

7:36the internet

7:37and ultimately wherever the default gateway is pointing wireless AP manager.

7:41This is indeed going to be the fabric wireless LAN controller.

7:46There's a big difference between a standard wireless LAN controller and a

7:50fabric wireless

7:51LAN controller that changes the way that our wireless operates.

7:55Access layer connectivity, that would be these guys right here.

7:58And that would be the fabric edge node.

8:03Fabric edge node.

8:05So the fabric edge node is what's going to form VX line tunnels among each

8:09other.

8:09They're essentially the access layer switches.

8:14This is also where we have connectivity down to our endpoints like our, hey,

8:21like our access

8:22points, like our laptops and desktops and voice over IP phones.

8:27Lastly, managing the endpoint tables, this is going to be that control plane

8:32node.

8:32If I want to send a packet to find a device somewhere out there in the SDA

8:38fabric, I'm

8:40going to have to know where it is.

8:47I don't need to know where everybody in the network lives, but I do need to

8:51know where

8:51this person lives.

8:53So I pull that information down, send it into a VX LAN tunnel and get it to

8:57where it

8:58belongs, whether that's another edge node or possibly to one of the border

9:03nodes.

9:03All right.

9:05Halfway done.

9:06This is question number five.

9:07What are the two controllers that manage the SD access architecture?

9:11Well, I just gave you this answer just a few questions ago.

9:14Hopefully we're paying attention.

9:16The answer here is going to be catalyst center and ice.

9:20So catalyst center is going to be primarily how we manage the solution.

9:24It's going to push configuration down, but Cisco has chosen to rely on another

9:29very solid

9:30controller and solid architecture that they have, which is the identity

9:34services engine,

9:35which is going to run Cisco trussec.

9:37So there's going to be an integration between ice and catalyst center.

9:41They haven't this again, at the least of the, as of the time of this video, we

9:45haven't

9:46actually seen Cisco combine those into one product.

9:48I don't expect them to anytime soon.

9:51I would expect them to leave them separated, but either way, until that changes

9:56, we are

9:57going to have to think about there being two different controllers in the SD

10:00access

10:00space.

10:01And that would be catalyst center, which again used to be known as DNA center

10:05or DNAC,

10:07as well as the identity services engine.

10:11Next up in an SD access to apology with five fabric edge nodes, where do the

10:16gateways and

10:17the switch virtual interfaces, another name for that would be the VLAN

10:21interfaces, where

10:22do these get deployed for each VLAN?

10:26So what we're driving at here is the concept of our any cast gateways and do we

10:30understand

10:31how exactly this works?

10:33And as a very quick overview, the idea here is, remember, we draw this

10:38architecture, we

10:39said, Hey, this is great.

10:40I've got a note over here.

10:42I've got a note over here.

10:43They're both part of the same subnet.

10:45And we have layer three segmentation up here.

10:48So yeah, I can tunnel via VX land between the two.

10:52But here's the question, where does the gateway live?

10:56Because of it lives over here, then this device is going to have to loop

11:00through and

11:01possibly just get trombone back to talk to another device that's out the same

11:05switch.

11:06If it's over here, we have to do it vice versa.

11:10And so really what we're trying to drive at here is we want D here, the gate

11:15ways to

11:16be duplicated onto all of the edges.

11:20So yes, if I have five different switches, like the scenario says, I'm going to

11:25deploy

11:25one SVI, let's say for VLAN 100, that VLAN 100 SVI is going to be is going to

11:34exist on

11:35all five edge nodes.

11:37So is this going to create a duplicate IP situation?

11:40Sure.

11:41If I try to SSH into this interface, I'm going to land on whichever one of

11:46those I happen

11:47to be the closest to.

11:48It's called any cast truly is referring to the nearest resource.

11:54And so in this case, we wouldn't want to use that interface to log into a

11:58switch.

11:59We don't know which switch we're logging into at that point.

12:01But what we could do is allow each one of these hosts to simply go up to the

12:05nearest

12:06instance of the SVI, which would be directly attached to them via the access

12:10switch.

12:11And then I can get routed to whatever other SVI or layer three interface I'm

12:15trying to

12:16get routed towards.

12:17So any cast gateways are a huge part of Cap and fabrics.

12:19We need to make sure we have a firm understanding of how those work.

12:24All right.

12:26Next question.

12:27What is the purpose of the policy plane and ice in the SD access solution?

12:32So we've mentioned a couple of times we got this policy plane.

12:35We're using ice.

12:36What's it doing?

12:37What exactly is it helping with?

12:39Well, it's going to help with access control.

12:42And that means a couple of things.

12:44First of all, it does mean onboarding users, but second of all, if I have a

12:49user here that's

12:50trying to communicate to a resource over here, are we going to allow this?

12:56This is very difficult to control in a layer two environment.

13:00And we might even have the same situation on the same switch where we ask the

13:04same question,

13:05hey, should we be allowed to communicate with each other at layer two?

13:09Well, ice and Cisco trussack and those scalable group tags, those are going to

13:14be very difficult

13:14to make it so yes, we can control whether or not this is allowed.

13:19And that's why we keep saying that Cisco integrated security at a foundational

13:23level

13:24CTS, Cisco trussack is a required part of the solution.

13:29Cisco did not want to deploy a campus fabric that didn't have security baked in

13:33and just

13:33layered on top, which is what seems to happen a lot with security.

13:37Instead, it was one of the first thoughts that they had was this solution needs

13:40to be secure.

13:42And they do that by managing access control via ice and Cisco trussack.

13:47All right, question number eight.

13:50And you know what?

13:51I might have been wrong.

13:52I think I've got one more question.

13:53So hang tight.

13:54We might have nine here.

13:55So what type of tunnels are used by fabric APs when integrated with SD access?

14:00Again, there's a big difference between when we are integrating with SD access

14:04and not,

14:05or not, then we're going to do something called wireless over the top and just

14:08sort of pretend

14:09like the access SD access is just sort of an underlay and we're going to build

14:15on top

14:16of that.

14:17But when we're integrated, what's interesting about this is I'm going to have

14:20my access

14:20switch here, which is really a fabric edge node.

14:24And I'm going to attach an access point here.

14:28And normally access points form a cap whap tunnel, some wherever the wireless

14:32line controller

14:33is in the environment.

14:34This time I'm going to form a VX LAN tunnel for the sake of data plane traffic

14:42to the

14:43fabric edge node.

14:44Now, I am still going to manage and maintain a cap whap node for control plane

14:50traffic,

14:50but for data plane traffic, meaning wireless station traffic, that is actually

14:55going to

14:56leverage the XLAN.

14:58So if you were thinking, hey, wait a second, we're using both of these.

15:01Well, technically correct.

15:03That web is still used for control plane, but VX LAN is really the answer we

15:07were looking

15:07for here because when we're integrated, we're really looking at using VX LAN

15:12for the sake

15:13of the data plane.

15:15All right.

15:16Now the last question, when deploying that wireless over the top solution that

15:20we just

15:21mentioned for an SD access deployment, where is the wireless LAN controller

15:26deployed?

15:27So at this point, we are building our access points such that we want to be

15:33able to form

15:34cap whap tunnels to the wireless LAN controller.

15:37And here we are building out of fabric.

15:40So where does it exist?

15:42Well, the answer is A. It lives outside the SDA fabric.

15:47It truly has to live on the other side of a border node in order for us to

15:52deploy wireless

15:54over the top.

15:55So at this point, I really am treating again this fabric, SD access as an under

16:00lay, and

16:01I'm going to form a cap whap tunnel through it all the way to the wireless LAN

16:05controller.

16:06And at that point, my wireless network basically behaves as if SD access wasn't

16:13even there,

16:14which is the whole point of turning a network into an underlay to begin with.

16:18So if we want our wireless to continue to operate as it is, we can use over the

16:22top.

16:23If we do want to integrate it into our SD access solution, it's going to make

16:26things a whole

16:27lot more efficient in a lot of ways because we'll have a whole lot less trom

16:30bone of traffic

16:31if we have to come back into the SD access world.

0:00So, in this scenario, we have a packet arriving on Switch1 towards a particular

0:04destination,

0:05and we need to know what exactly SD Access does with this packet and how

0:10exactly it knows

0:11where to send it and if it doesn't know where to send it, what does it do with

0:14it?

0:15So, looking through these questions, what type of message is first sent by

0:18Switch1?

0:19Well, it's going to send a request to the control plane node because, again, we

0:24need

0:25to pull down the information.

0:28We need to fix this pull-based methodology we really need to start to get used

0:32to because

0:32we're no longer pushing routes everywhere.

0:35Furthermore, when we talk about routes, we are talking about those endpoint

0:39identifiers

0:40that LISP manages.

0:41Now, we might think of those as routes like going to a /24, but in the case of

0:47SDA, we're

0:48talking about individual /32s.

0:51We need to know where this specific host lives because the subnet is everywhere

0:56.

0:56I mean, we've probably got a host over here that's 10.100.1.51.

1:02I mean, they could be adjacent from an IP address perspective, so it doesn't do

1:06me any good

1:06to know where the subnet lives because the subnet kind of lives everywhere.

1:10I need to know where this specific host lives, and so that's the responsibility

1:14of the control

1:15plane node.

1:16As soon as Switch2 sees a packet from this host, we're going to register that

1:21with the

1:22control plane node.

1:24And now, when we go and we make a request of the control plane node, we're

1:29going to pull

1:30that information down.

1:31Yeah, we could push this information everywhere, and then everybody knows where

1:35every single

1:36host in the network is.

1:37It doesn't scale particularly well, and keep in mind also that we can cache

1:41this information.

1:43I don't have to do this every single time.

1:45I can know that, hey, .50 goes to Switch2, and I can remember this over the

1:50course of

1:51time.

1:52And yeah, eventually I'll clear that out if traffic stops, but as long as

1:55traffic is

1:56flowing to that host, I'm going to keep this information in the cache, and I

2:00don't have

2:00to go all the way up to the control plane node in order to get that information

2:04again.

2:05So that's how we go about doing this.

2:07The first step is to send that request up to the control plane node, and then

2:11what happens

2:12if it has an entry?

2:13Well, we respond.

2:14We send a response back to Switch1, and it encapsulates this into VXLAN and

2:22sends it

2:22across to Switch2.

2:24And we use VXLAN because it maintains the entirety of the Layer 2 frame,

2:28including the

2:28original Ethernet headers.

2:30And this allows us to, I really like drawing out, make the dotted line

2:35connection here so

2:36that if we have VLAN 100 on one side, we can have that same Layer 2 VLAN over

2:42on the other

2:42side, despite the fact that our fabric is built on Layer 3 for the sake of

2:47scaling and

2:48an eliminating spanning tree protocol.

2:49It's a beautiful thing.

2:51So, what happens if the control plane node doesn't have an entry though?

2:55What if it says, "Hey, I don't know where .50 is."

2:58In fact, let's just change the scenario here ever so slightly.

3:01Now let's say a new packet arrives and it's destined for .65.

3:06And so we send our pull request and we don't know where .65 is.

3:13Maybe it's part of a completely different subnet.

3:15Either way, we're going to let Switch1 know we don't know this, and therefore

3:18Switch1

3:19is going to do the only thing it knows to do, which is to send it in VXLAN over

3:25to the

3:25border node.

3:27The border node is going to have to decide what to do with this.

3:30And maybe it has a route and it knows to go out towards the core of the network

3:37.

3:37But the reality is that if we don't know where it is, it's probably just going

3:40to follow

3:41the default route, which ultimately takes us towards the internet.

3:45And that's the goal here because we do still need to have a default route path

3:49in the fabric,

3:50and that would be handled by the border node.

3:53Remember that there are internal border nodes, right up here.

3:57There's internal border nodes that handle internal connections.

4:00There's external border nodes that handle internet connections, and they can

4:05certainly

4:05have both roles on a single device.

4:09Now lastly, how is the packet encapsulated and where is it sent?

4:12We kind of answered that throughout this whole process.

4:14The big thing is it's going to use VXLAN in order to maintain the layer two

4:19information.

4:20So that brings us to the end of this review on the software defined access and

4:24software

4:25defined when lots of information to unpack.

4:28As a set of the very start, a lot of review like this to help you identify your

4:32areas

4:32of weakness.

4:33If you have anything or identified any particular concerns, then go back and

4:37watch those videos

4:39in those skills in order to make sure we've got it all down before moving on.

4:43Otherwise, I hope this has been informative for you, and I'd like to thank you

4:46for viewing.