Review Software Defined Architectures

0:00It's always tempting to want to just move on to the next subject, but we've just covered some really big ones. Software-defined weigh-in, software-defined access, these are massive new technologies, relatively new technologies, because at this point they've been around for quite a few years, but in the grand scheme of things, routing and switching didn't change a whole lot for a long time. And then all of a sudden we get software-defined infrastructure, so SD access completely changes the way we deploy access layer, switching, and software-defined win completely changes the 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 brakes, take a breath, and remember everything that we've been learning, because there was a lot of information. It was hard for me to pack all of that information we talked about into a decent summary, because there was just so much. So let's be sure to take a few moments here to remember what we've learned to lock it in for the future, and hey, bookmark this skill as well, because later on when you're preparing to maybe go take the exam, rather than going back through every single skill, maybe we can target some of these review skills, say let's just go through that .

1:10And the goal here is obviously number one, we want to answer the questions and get them right, but don't be discouraged by getting the answers wrong either, because what that allows us to do is say, "Hey, I need to work on that." It helps us to identify our areas of weakness. Not one of us has all of this memorized and all of this down, so when we're going through this, make sure to flag any questions, say, "Hey, I need to learn more about that or remember more about that." I can go back to the skill that's referenced in the quizzes and make sure that I can answer that question moving forward.

1:44So as far as the format's concerned, we're going to do some quiz questions, we 're going to 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 up until now, which is to ask some quiz questions, but I'm not going to pause the video and give a lengthy silence. What I'd encourage you to do is once we get done reading the quiz question, you hit the pause button and make sure you can answer it yourself before unpause it and watching the solution in order to verify. So for example, with this question here, what are the four planes of operation for Cisco SD-WAN? This is an open ended question. So again, hit the pause button, maybe grab a piece of paper and a pad of paper, a piece of paper and a pencil, whatever you need to write stuff down and make sure that you can answer this question yourself before again, we start to talk about the solution .

0:45So what is the solution here? Well, Cisco's SD-WAN architecture is pretty sophisticated and it doesn't involve these four planes of operation. We might be used to control plane and data plane when we're talking about normal network operations. And certainly that's going to be the first two. We're going to have a control plane of operation, which allows us to share routes with one another, make sure we know how to encapsulate our traffic and get it to the destination. We have the data plane, which involves building those secure tunnels and allowing us to send traffic from one WAN device to another WAN device.

1:22But there are a couple others here as well. First of all, we have a management plane of operation. This is how we manage the entire SD-WAN infrastructure from that single pane of glass is a huge part of software defined infrastructure is getting us away from piecemealing everything, configuring dozens of devices to try to work in concert and orchestration with one another. Instead, we simply log into one interface, one device and tell the network how we want it to run and it pushes that configuration everywhere.

1:55It has an immense benefit to software defined architectures. The last plane of operation is that orchestration plane. This is especially focused on onboarding. We want to be able to streamline our ability to spin up new software defined W AN, especially those WAN edge devices and the orchestration plane is going to help with the onboarding process, help with dealing with our NAT, bypass and such. And so all four of these planes of operation are mission critical for SD-WAN operation.

2:28Question number two, match the SD-WAN device to its plane of operation. So we just talked about the four different planes. And what we find is that there's one device that belongs to each one of those planes of operation. So which one is which here? Well the SD-WAN edge devices would be the device that's actually sitting here at the edge of our network, of our wide area network specifically. And so usually this is our layer three router type of device that's going to communicate into the site.

3:00And then it will have ideally a handful of wide area networking circuits back up into the network. So this is going to be responsible for sending traffic from one edge device to another edge device, which will communicate with another site. Maybe this is the headquarters. But either way, this device at the edge, this is part of our data plane of operations. So the V-Manage. The 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. I'm going to log into V-Manage and it's going to push configuration everywhere. The V-Smart, this is the control plane device. So my V-Smart are going to receive routes and routing information and it's going to push it down to the other WAN edge devices. And 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. So the V-Bond has to be out here with a public IP address. It has to be reachable and fully accessible because again of that net bypass part of the operation. So these are the four devices. Also keep in mind, that Cisco has started to come up with new names for all of these devices. In fact, the edge device used to be known as the V-Edge and also the C-Edge as we talked about.

4:33So we're no longer calling the V-Edge. Well, Cisco started to migrate all of these as well. So when it comes to the V-Manage, we're talking about the SD WAN manager. With the V-Smart, we're talking about the controller, which fits pretty well with the control plane of operations. And then this is kind of the tricky one, orchestration plane, instead of calling it the V-Bond, they are now calling it the validator. So let's start to keep these new terms in mind as well as we learn the architecture and start to get our hands on it.

5:09It's going to depend on which Cisco documentation we're looking at, whether it 's calling it the old names or the new names. And so that's why it's going to be important that we know both. Question number three, what type of tunnels are used for the SD WAN data plane? So the data plane is going to use secure tunnels that communicate between our SD WAN edge devices. And so those secure tunnels are going to be formed using IPsec. So keep that in mind that when we've got our devices at the edge here, we've got lots of physical circuits and physical paths to one another.

5:48But one of the ways that SD WAN simplifies everything is by building tunnels. So I'm going to build, for example, an IPsec tunnel here across one WAN circuit over here as well with another WAN circuit or across the other WAN circuit. If they happen to both use the internet, we might see a full mesh of tunnels forming. But either way, these data plane tunnels are using IPsec. So when a packet shows up on this router, it needs to go over to this other site, it's going to ride one of those IPsec tunnels to the other side.

6:19That's what we mean by data plane operation. And it's very important that we're using IPsec because a huge part of what we 're trying to accomplish with SD WAN is not only simplifying our traffic flow and giving us more control over it, but also adding a layer of security, whether that's because we're riding over the internet or because we're using a service provider technology like MPLS that would be shared with other organizations. And 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 means something different, especially when we're already talking about IPsec tunnels. But within SD WAN architecture, the VPN is sort of like a VRF, which we'll be talking about in more detail coming up soon. But a VRF is essentially just a completely different routed domain. And so the answer here is going to be D. It's a segmented routing domain. And the primary reason we have this is for the sake of multi-tenancy. SD WAN is a technology that regularly gets deployed by service providers, and they sort of sell the solution and manage it.

7:30But the customer doesn't get to interface with it. We, as the service provider, are managing a multi-tenant environment, and therefore every customer is going to get their own VPN. That's why it's called a virtual private network, even though from a strict routing and switching perspective, it really is closer to a VRF. And so we need to think of it from both perspectives there. But either way, it is a segmented routing domain, and it's going to allow us to build things 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 most situations outside of some of the other VPNs that are used for management. But if we have a use case for deploying multiple VPNs, then we can certainly take advantage of that as well. All right, question number five. We're halfway done, by the way. I didn't say it at the start, but we have eight questions. So we've answered four of them, four more to go, starting here with question number five. So what is the full VPN range in Cisco SD WAN and how are VPNs zero and 512 used?

8:37Well, the full range here originally actually was zero to 512, which is kind of interesting because, yeah, 512 is a binary number, but it goes one past the value. Like if we were actually using nine bits, then we would have zero to five 11. So we know we have more bits there. It's just the Cisco and Viptela, especially originally, we're restricting it. The 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 binary number. Those last five must be reserved by Cisco for some reason at this point. But either way, that's the full range. However, two of those values, zero and 512 are reserved. And the reason why is zero and 512 of all these numbers comes back to the fact that it used to be zero to 512 was allowed with the first and last being reserved. So 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. So this is the usable range of VPN IDs and zero and 512. Again, our reserve. So what are they reserved for? Well, VPN zero, this is going to be reserved for the actual WAN circuits, which is the ultimately saying this is the underlay. Again, this is a completely segmented isolated routing environment. And what we're trying to create here is the idea that whatever this underlay looks like with multiple routers in the path that I'm just forming this tunnel and allowing my routes to flow over this tunnel.

10:24And I don't need to know these routes in the overlay and the underlay doesn't need to know the overlay routes. So we're creating this. Draw it like this here. We're creating these two different routing domains. We're creating the underlay here and we're creating the overlay up here. And generally speaking, we don't want those routes to mix, which is why we have again, if we think about VPNs as VRFs, that's why we have our YN circuits listed and dedicated as a as VPN zero.

10:55Now we also have VPN 512. This is used for out of band management. And so this is really helpful and useful for organizations that like to isolate their management and keep that in a dedicated route and domain. But as far as our actual usable VPNs for our data traffic, we're going to have to pick one of these VPNs. Again, if we're an enterprise shop, we're probably just going to pick one of these. If we're a service provider, then we're going to use a whole lot of them because every customer is going to get their own.

11:28Question number six, it's about T locks here. So what are the three components of a T lock, a transport locator? So the T locks are interesting because the T lock essentially defines a path to a router or really a WAN edge device. And yet it doesn't actually tell us how to get there. Kind of curious. We're going to need to rely on OMP to say, Hey, if you're trying to get to this T lock, go to this address. So what's the purpose of the T lock? Well, 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 presented by the WAN edge device, sort of describing itself and describing these different paths. So we can think of them as paths and how would we describe paths? Well, first of all, we're going to include the system IP here. So the system IP is again, not a routable or necessarily a routable IP address. It'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. If I have different paths, the second part of the tuple is going to be the concept of the color. The color is essentially trying to say that this is part of a particular wide area network domain. So we've mentioned that a WAN edge device likely has at least a couple of upl ink circuits, especially if we're deploying SD WAN, if we just have a single uplink circuit, SD WAN isn'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 multiple circuits, we might even have three or four circuits at some critical sites. Well, this creates three different service provider paths. And as part of the T lock, I want you to know that, Hey, if you're trying to come in on this path, you're going to use this particular service provider. So the color remember is a string. And for better or worse, we can't define that ourselves, but Cisco gives us a lot of options. And 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. But this color is going to tell us about how I can approach and use this T lock . The last thing we need is the encapsulation. So the encapsulation is going to tell me what I'm using, whether it's IP sec or GRE. But we just got done saying that IP sec is used at the data plane. And in every SD WAN deployment, this should be the case. Outside of maybe a lab environment, I suppose.

14:09But we do have GRE as an option. GRE is essentially just saying, Hey, we're going to use an unsecured tunnel rather than relying on the security of IP sec. There might be some really niche type of situations or corner case scenarios where we can't encrypt our traffic for one reason or another. Maybe it has to do with the country of operation. But generally speaking, we're going to be using IP sec. As I have said, keep in mind GRE is technically an option. And 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. It's the system IP. It's the color and it's the encapsulation that can include in the T lock. And remember, these don't by themselves tell us how to route and get here. We're going to need OMP to glue that part together later. Question seven, which SD WAN device serves as an OMP route reflector among the WAN edges? Well, the answer here is just straight up the V smart, otherwise known as the SD WAN controller, I suppose with modern terms.

15:15But either way, this V smart is going to serve as a route reflector. What do we mean by route reflector? And why did I use quotes here to describe it? Well, it's because route reflector is actually a BGP term. But as we've said a few times, OMP is very BGP like in its behavior. One of the ways that's BGP like is that it can perform its operations as a route reflector. Because unlike with our other routing protocols that use multicast, we're not just forming relationships with everybody.

15:47We can kind of choose who we form relationships with. And so I might have multiple WAN edge devices here. And I want to share a route into this space. Well, if I'm not using intelligence here, as far like trying to make it a little more efficient, I might have many, many, many WAN edges here. And if I was not going to use a route reflector or anything other, again, more efficient, I'd have to share this with every single other WAN edge device so they know how to get to this route.

16:23Well, fortunately, I don't have to worry about that. I don't have to maintain a full mesh of adjacencies, which as we can imagine, as this grows out, it would become very unsustainable for us to have that many OMP adjacencies or whatever routing protocol we're using at that point. Instead, the V smarts going to serve as a route reflector, which means I advertise it one time to the V smart and it's responsible for pushing it down to all of the other WAN edge devices. So the V smart is a very important part of this.

16:54OMP is a very important part of this. And in this case, our focus is just simply trying to say, "Hey, I've got this route subnet A I want you all to know about." And the V smart helps me get the word out to the rest of the WAN edges that route A lives on my port. All right, question number eight, the last question, which six parameters are used to identify a traffic flow for application aware routing when DPI isn't in use? Cisco's deep packet inspection or DPI is really great for identifying traffic types.

17:28And this is important because as part of deploying SD WAN, I can look at traffic coming in and identify the traffic. And depending on the traffic type, I might want to send some traffic one way and some traffic another way. For example, I might want to send my bulk traffic across an internet circuit, but my voiceover IP traffic should go out towards MPLS, something along those lines. So 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 require an additional license. And we make sure we have the right hardware in place and all of that. So we have a backup plan, which is to use the six tuple. We talked about the three tuple, tuple earlier with T locks. Now we're talking about the six tuple. So we're simply going to equate a flow to the six tuple. If we share these six pieces of information, then we are part of the same traffic flow.

18:31And so that's how we're going to identify our traffic. So how do we do this? Well, we're going to take a look at the six different, six different, I guess, identifiers. We have to look through each one of these. So first of all, we're going to look at the IP address for source and destination. So that would be two of them. We're not going to look at the MAC addresses because MAC addresses can be deceptive. If we're routing between two different routers, well, the source of destination MAC address, those are brand new. They're just for those routers.

19:01It doesn't tell us what actually is communicating. So we don't want to rely on MAC addresses. IP addresses are persistent end to end. So would be the source and destination port. That's another two of our six. So we're up to four so far. And then we're also going to take a look at DSCP and protocol number. So these would be our six points of identifications. It's going to allow us to identify traffic as it comes into the router, make sure that's going out the appropriate up link when we're using application aware routing.

19:31So that ends the quiz for SDWAN. Let's go ahead and jump into a challenge to make sure that we fully grasp how the architecture comes together.

0:00All right, let's draw some tunnels here on this diagram. So we're talking about the TLS and DTLS tunnel for non-data plane traffic. We're really talking about seeing these tunnels establish among all of the different devices for the most part. And so we're going to see, for example, our edges form TLS or DTLS tunnels to the V smart and same thing over to the V manage. But one thing to keep in mind is that even though we do form DTLS connections to the V 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. Meanwhile, we do maintain a full mesh of TLS or DTLS connections among the different non-data plane nodes as well. So quite a few of these TLS or DTLS tunnels in our environment. So let's now talk about the IPsect tunnels. So the IPsect tunnels are going to be used for data plane traffic, and those are only going to be maintained among the edge devices.

1:11Now these IPsect tunnels usually are going to end up being built in a full mesh fashion across different WAN fabrics. So if we have multiple WAN fabrics, then we need to figure out, okay, well, maybe I form tunnels through this one as well as through this one in order to get to the same WAN edge device. For now, we're just going to show this as a full mesh among the edge devices, but do keep in mind as well that we have partial mesh options. So it's not so much that it has to be full mesh.

1:42We could do partial mesh. We have control over that, but in a lot of situations, we're forming a lot of IPsect tunnels among our edge devices. Now lastly is the OMP route exchanges. As we talked about in the quiz, if I am exchanging routes with the V smart as a edge device, well, those routes will get pushed down from the V smart to the other edge devices thanks to the fact that it's going to serve as a sort of a route reflector. So I don't need to share routes directly with other edge devices, and we don't need to share routes outside of the V smarts.

2:18So that's how a lot of these connections come together. Let's just try to remember how the different tunnels are formed and what those look like and which devices are forming those tunnels.

0:00All right, it's time to jump into software defined access. So SDA is all about giving us a method for deploying a campus fabric. Campus fabric is going to be a new way of deploying our access layer. So we don't have to choose between layer two and layer three. So once again, pause the questions before we get into the answers in order to take a crack at it yourself. So question number one here, and there's eight questions this time as well. What are two goals for deploying campus fabrics? Well, what we're trying to do once again is evaluate layer two versus layer three to the access layer.

0:35And both of these have pain points. Layer two is flexible, but it has spanning tree protocol. Layer three has an immense amount of scale, but we lack the flexibility. And so we want to try to find the best of both worlds. And this leads us to the campus fabric. The idea of the campus fabric is I will build a layer three underlay. So we're basically embracing layer three to the access. So 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. We've got this concept where yeah, I'm layer three segmented, but I've got hosts over here. I've got hosts over here and they're all part of the same subnet, whatever that is pretty fascinating and really neat. And what this allows us to do is first of all, hey, eliminate spanning tree. One of the best things you can ever tell a network engineer is we'd never have to deal with spanning tree ever again, because our architecture is fully layer three.

1:40We're not going to eliminate routing. We're actually going to deploy routing some kind of routing protocol under the hood there. And the other goal here is to maintain our layer two networks. We're not looking to remove them. So in that sense, we're also embracing the layer two side of things. I mean, I really can't describe any better. It's a best of both worlds approach. We don't have to worry about the pain points for either one, but we get the benefits of each one. It's pretty fascinating. Now security is not an inherent part of deploying campus fabrics.

2:13It is an inherent part of SDA. It's go baked security into SDA from the ground up. But for this question, we're specifically talking about campus fabrics independent of SD access. Question two, what are the four layers of the Cisco SD access solution? So we talked about the four layers for SD when now we're talking about the four layers of SD access. So 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 layer, and the management layer. Now we're not going to dive too deep into any one of these, but as a very quick overview, remember, a physical layer involves the different devices that are going to be at play here. We've got specific devices, catalyst nine case, for example, that we're going to want to 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 wireless land controllers in there as well. The network is where things start to get a little bit interesting. We've got those three different components we're going to be talking about here that allow us to build out our fabrics. And so I won't spoil it because we're going to ask questions about it coming up . But if you do recall those three different protocols that are very important as part of the network layer. The controller is going to consist of our two controllers. First of all, our primary one, what used to be known as DNA center or D-NAC is now known as catalyst center.

3:51And then we've also got ICE for identity services engine and identity management. And then management layer itself, this is going to be where we have a graphical user interface in order for us to manage the environment. But we've also got REST APIs. And we can be very programmatic in our approach to deploying software defined access. So let's remember these four different layers. They're very different from SD-WAN. We need to make sure that we're keeping all of these layers straight in our minds. All right, I said I wasn't going to spoil it.

4:22And so now we're going to talk about those protocols. So match the protocol to the plane of operation within the SD access network layer. So now we've got layers and we've got planes. What's going on here? Well, when we're talking about planes of operation, we're talking about the data plane, control plane and policy plane. This sounds a little closer to those planes of operation, the layers, whatever we want to call them in SD-WAN. Within SD access, we're going to take that network layer and we're going to split it up into different planes.

4:55And specifically these planes of operation. So this is a layer. These are planes. Once again, we have to keep in mind which one is which, but the planes fit into the layer. Now the data plane, this is where we're going to, again, we've got to identify the protocols we're using at the data plane, we're forming tunnels. We saw on SD-WAN, we're using IPsec tunnels, but that won't work with SD access where we need a layer two. So we're going to rely on a different mechanism that gives us layer two and that is the X-LAN.

5:28We'll be diving into VX-LAN in more detail coming up here. And by the way, we'll be diving into something else in more detail coming up, which is the control plane protocol known as LISP, which changes the way we share routes. We don't push routes everywhere just in case anymore. We just pull them in on an as needed basis and the policy plane is going to use Cisco trussec. Cisco trussec is going to include a security tag, something called a scalable group tag used 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 another device? It really helps us out with onboarding devices and generally speaking access control. Question four, identify the SD access device type that's responsible for each of these operations. We need to go through all four of these. So what device type, first of all, what are we talking about with the device types? Well, I'm thinking about things like the control plane nodes, we're thinking about the border nodes. Some of these guys, we've got the just simply the fabric edge nodes.

6:37These are a big one. And then out of all of these, we might also be concerned about fabric wireless and controllers. So we'll look at gateway access to non-SDA networks. When we're talking about non-SDA, we're talking about the external world. We've got a fabric here. We've got all of these switches. These are all access closets. At some point, we're going to need to get out to the network core to route out to other networks. Maybe that's the internet. Maybe that's the data center, wherever we're going.

7:09Well, that's going to be the responsibility of the fabric border node. And yes, Cisco does like to include the word fabric and we should probably include it as well. So we have a fabric border node that sits here and we're going to send traffic to the border node with either the border node telling us, hey, I've got a route to the data center, or simply put, I don't think that we know where this destination is. So I'm going to forward it to the border node, hoping it's destined out towards the internet and ultimately wherever the default gateway is pointing wireless AP manager.

7:41This is indeed going to be the fabric wireless LAN controller. There's a big difference between a standard wireless LAN controller and a fabric wireless LAN controller that changes the way that our wireless operates. Access layer connectivity, that would be these guys right here. And that would be the fabric edge node. Fabric edge node. So the fabric edge node is what's going to form VX line tunnels among each other. They're essentially the access layer switches.

8:14This is also where we have connectivity down to our endpoints like our, hey, like our access points, like our laptops and desktops and voice over IP phones. Lastly, managing the endpoint tables, this is going to be that control plane node. If I want to send a packet to find a device somewhere out there in the SDA fabric, I'm going 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 know where this person lives. So I pull that information down, send it into a VX LAN tunnel and get it to where it belongs, whether that's another edge node or possibly to one of the border nodes. All right. Halfway done. This is question number five. What are the two controllers that manage the SD access architecture? Well, I just gave you this answer just a few questions ago. Hopefully we're paying attention. The answer here is going to be catalyst center and ice.

9:20So catalyst center is going to be primarily how we manage the solution. It's going to push configuration down, but Cisco has chosen to rely on another very solid controller and solid architecture that they have, which is the identity services engine, which is going to run Cisco trussec. So there's going to be an integration between ice and catalyst center. They haven't this again, at the least of the, as of the time of this video, we haven't actually seen Cisco combine those into one product. I don't expect them to anytime soon.

9:51I would expect them to leave them separated, but either way, until that changes , we are going to have to think about there being two different controllers in the SD access space. And that would be catalyst center, which again used to be known as DNA center or DNAC, as well as the identity services engine. Next up in an SD access to apology with five fabric edge nodes, where do the gateways and the switch virtual interfaces, another name for that would be the VLAN interfaces, where do 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 understand how exactly this works? And as a very quick overview, the idea here is, remember, we draw this architecture, we said, Hey, this is great. I've got a note over here. I've got a note over here. They're both part of the same subnet. And we have layer three segmentation up here. So yeah, I can tunnel via VX land between the two. But 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 through and possibly just get trombone back to talk to another device that's out the same switch. If it's over here, we have to do it vice versa. And so really what we're trying to drive at here is we want D here, the gate ways to be duplicated onto all of the edges. So yes, if I have five different switches, like the scenario says, I'm going to deploy one SVI, let's say for VLAN 100, that VLAN 100 SVI is going to be is going to exist on all five edge nodes.

11:37So is this going to create a duplicate IP situation? Sure. If I try to SSH into this interface, I'm going to land on whichever one of those I happen to be the closest to. It's called any cast truly is referring to the nearest resource. And so in this case, we wouldn't want to use that interface to log into a switch. We don't know which switch we're logging into at that point. But what we could do is allow each one of these hosts to simply go up to the nearest instance of the SVI, which would be directly attached to them via the access switch.

12:11And then I can get routed to whatever other SVI or layer three interface I'm trying to get routed towards. So any cast gateways are a huge part of Cap and fabrics. We need to make sure we have a firm understanding of how those work. All right. Next question. What is the purpose of the policy plane and ice in the SD access solution? So we've mentioned a couple of times we got this policy plane. We're using ice. What's it doing? What exactly is it helping with? Well, it's going to help with access control.

12:42And that means a couple of things. First of all, it does mean onboarding users, but second of all, if I have a user here that's trying to communicate to a resource over here, are we going to allow this? This is very difficult to control in a layer two environment. And we might even have the same situation on the same switch where we ask the same question, hey, should we be allowed to communicate with each other at layer two? Well, ice and Cisco trussack and those scalable group tags, those are going to be very difficult to 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 level CTS, Cisco trussack is a required part of the solution. Cisco did not want to deploy a campus fabric that didn't have security baked in and just layered on top, which is what seems to happen a lot with security. Instead, it was one of the first thoughts that they had was this solution needs to be secure. And they do that by managing access control via ice and Cisco trussack. All right, question number eight.

13:50And you know what? I might have been wrong. I think I've got one more question. So hang tight. We might have nine here. So what type of tunnels are used by fabric APs when integrated with SD access? Again, there's a big difference between when we are integrating with SD access and not, or not, then we're going to do something called wireless over the top and just sort of pretend like the access SD access is just sort of an underlay and we're going to build on top of that. But when we're integrated, what's interesting about this is I'm going to have my access switch here, which is really a fabric edge node.

14:24And I'm going to attach an access point here. And normally access points form a cap whap tunnel, some wherever the wireless line controller is in the environment. This time I'm going to form a VX LAN tunnel for the sake of data plane traffic to the fabric edge node. Now, I am still going to manage and maintain a cap whap node for control plane traffic, but for data plane traffic, meaning wireless station traffic, that is actually going to leverage the XLAN.

14:58So if you were thinking, hey, wait a second, we're using both of these. Well, technically correct. That web is still used for control plane, but VX LAN is really the answer we were looking for here because when we're integrated, we're really looking at using VX LAN for the sake of the data plane. All right. Now the last question, when deploying that wireless over the top solution that we just mentioned for an SD access deployment, where is the wireless LAN controller deployed? So at this point, we are building our access points such that we want to be able to form cap whap tunnels to the wireless LAN controller.

15:37And here we are building out of fabric. So where does it exist? Well, the answer is A. It lives outside the SDA fabric. It truly has to live on the other side of a border node in order for us to deploy wireless over the top. So at this point, I really am treating again this fabric, SD access as an under lay, and I'm going to form a cap whap tunnel through it all the way to the wireless LAN controller. And at that point, my wireless network basically behaves as if SD access wasn't even there, which 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 top. If we do want to integrate it into our SD access solution, it's going to make things a whole lot more efficient in a lot of ways because we'll have a whole lot less trom bone of traffic if 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 destination, and we need to know what exactly SD Access does with this packet and how exactly it knows where to send it and if it doesn't know where to send it, what does it do with it? So, looking through these questions, what type of message is first sent by Switch1? Well, it's going to send a request to the control plane node because, again, we need to pull down the information. We need to fix this pull-based methodology we really need to start to get used to because we're no longer pushing routes everywhere.

0:35Furthermore, when we talk about routes, we are talking about those endpoint identifiers that LISP manages. Now, we might think of those as routes like going to a /24, but in the case of SDA, we're talking about individual /32s. We need to know where this specific host lives because the subnet is everywhere . I mean, we've probably got a host over here that's 10.100.1.51. I mean, they could be adjacent from an IP address perspective, so it doesn't do me any good to 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 of the control plane node. As soon as Switch2 sees a packet from this host, we're going to register that with the control plane node. And now, when we go and we make a request of the control plane node, we're going to pull that information down. Yeah, we could push this information everywhere, and then everybody knows where every single host in the network is. It doesn't scale particularly well, and keep in mind also that we can cache this information.

1:43I don't have to do this every single time. I can know that, hey, .50 goes to Switch2, and I can remember this over the course of time. And yeah, eventually I'll clear that out if traffic stops, but as long as traffic is flowing to that host, I'm going to keep this information in the cache, and I don't have to go all the way up to the control plane node in order to get that information again. So that's how we go about doing this. The first step is to send that request up to the control plane node, and then what happens if it has an entry?

2:13Well, we respond. We send a response back to Switch1, and it encapsulates this into VXLAN and sends it across to Switch2. And we use VXLAN because it maintains the entirety of the Layer 2 frame, including the original Ethernet headers. And this allows us to, I really like drawing out, make the dotted line connection here so that if we have VLAN 100 on one side, we can have that same Layer 2 VLAN over on the other side, despite the fact that our fabric is built on Layer 3 for the sake of scaling and an eliminating spanning tree protocol.

2:49It's a beautiful thing. So, what happens if the control plane node doesn't have an entry though? What if it says, "Hey, I don't know where .50 is." In fact, let's just change the scenario here ever so slightly. Now let's say a new packet arrives and it's destined for .65. And so we send our pull request and we don't know where .65 is. Maybe it's part of a completely different subnet. Either way, we're going to let Switch1 know we don't know this, and therefore Switch1 is going to do the only thing it knows to do, which is to send it in VXLAN over to the border node.

3:27The border node is going to have to decide what to do with this. And maybe it has a route and it knows to go out towards the core of the network . But the reality is that if we don't know where it is, it's probably just going to follow the default route, which ultimately takes us towards the internet. And that's the goal here because we do still need to have a default route path in the fabric, and that would be handled by the border node. Remember that there are internal border nodes, right up here.

3:57There's internal border nodes that handle internal connections. There's external border nodes that handle internet connections, and they can certainly have both roles on a single device. Now lastly, how is the packet encapsulated and where is it sent? We kind of answered that throughout this whole process. The big thing is it's going to use VXLAN in order to maintain the layer two information. So that brings us to the end of this review on the software defined access and software defined 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 areas of weakness. If you have anything or identified any particular concerns, then go back and watch those videos in those skills in order to make sure we've got it all down before moving on. Otherwise, I hope this has been informative for you, and I'd like to thank you for viewing.