Describe Wireless Architecture

0:00When we think about the management of our wireless networks, things are a little bit different than when we're managing our switches and our routers, primarily because of the sheer number of access points. We're talking about wireless communications. We usually have an access point, which is our network device that maintains a wired connection to the switched infrastructure. And then we're wirelessly communicating to devices that are referred to as stations. And abbreviated like so with STA capitalized.

0:33So sometimes I'll refer to these as clients as well, but either way we have devices that are wirelessly communicating to these access points. And I know that back in the day when I was first just very young and entering into the industry I was responsible for largely just physical layer things like hanging access points. And eventually I learned how to do site surveys. And I would go into a school and this is like in the mid 2000s and I could do a wireless site survey and for the entirety of this building we just need to have six access points.

1:07And the reason for that was because six access points would get the job done. We were using 2.4 gigahertz which could go a lot further. We had lower client density and so we didn't need a lot of AAPs. And so we might go into a school system and across many different schools maybe in total we had 50 or 60 access points. So still a lot of AAPs but it was at least somewhat manageable to manage every single AP on its own. But even 60 was a lot and as we've had to get into more modern applications and modern wireless devices we've seen the number of AAPs increased dramatically.

1:47That same school system that maybe needed 60 access points today might need 300 or 600. And so we needed a better way even in the mid 2000s and late 2000s to manage these access points. And that led to the creation of the lightweight architecture. In a lot of ways lightweight wireless was sort of a first step into the world of software defined networking.

2:19Because what we did was we said that the amount of intelligence that's required on this access point here could be lowered. I didn't write that very well. So let's try that again. We could lower the intelligence level and ultimately the functions of the software that's running on this access point. So it's a more lightweight software image which is where the name comes from. And then we are connecting back to a wireless LAN controller.

2:50This wireless LAN controller is responsible for maintaining the management of that device. And so we could have again lots and lots of access points all communicating back to the wireless LAN controller. And I don't have to manage each one of these access points individually, which is what I had to do before a lightweight came around back when it was what we refer to as an autonomous architecture. So lightweight does a lot of good for us and a lot of times it's commonly centered around the idea of deploying wireless LAN controllers into our environment.

3:26And this is a beautiful thing because if I were to deploy let's say another access point into the environment, it will automatically find the wireless LAN controller. And there's a lot of ways that we can help it discover it. We'll talk about that momentarily. And the wireless LAN controller is going to push configuration down. Furthermore, as these access points are nearby each other, we might have one access point on channel 40 in the 5 gigahertz space. And therefore we wouldn't want this wireless or access point to be on channel 40 instead.

4:01The wireless LAN controller would say, all right, we're detecting channel 40 in the area. Maybe we're detecting a bunch of other channels. We think you should deploy on channel 60. And this might change over time. But in the end, we're trying to dynamically manage a wireless environment that isn't static. Wireless needs change dramatically even within the course of a day. The amount of interference and the amount of other wireless activities could prompt us to change not only the channel, but also the transmit power level.

4:35And so the wireless LAN controller is capable of monitoring the wireless environment and adjusting it on an as needed basis. From a, again, management perspective, me as the admin, I don't have to go out and manage all of these access points. Instead, I manage them all through one device. That's the wireless LAN controller. So what exactly is this wireless LAN controller? Well, for the most part, a wireless LAN controller is going to be a physical device or appliance that's going to live on the network somewhere.

5:15And where it lives is very important. And we'll talk about that later on. Now they can also take different forms as well these days. For example, we could deploy it as a virtual appliance. And a virtual appliance just means that it has to live on one of my virtual hosts inside my data center. We don't often want our wireless LAN controllers to live inside of our data center. And so we could deploy this on a virtual host that connects in at a distribution layer somewhere. But either way, we could deploy the Cisco makes it available.

5:46First is download the software for a wireless LAN controller. And rather than purchase an appliance that is a physical set of hardware like CPU and memory and all of these things, I can create my own server and deploy the software onto that. So that's the concept of deploying it as a virtual appliance. We can also deploy it into the cloud as a virtual appliance. Now there's two different aspects to the cloud. So first of all, I could deploy this concept here, but rather than deploying it onto my own physical host, I just deploy the virtual appliance into a cloud space known as infrastructure as a service.

6:30It's basically me saying I'm going to spin up a virtual machine in the cloud and run it there. And I could also run this as a controllerless environment. The best example of this from a Cisco perspective would be Miraki. Miraki is a product line that originally was a competitor to the Cisco. Cisco acquired them quite a long time ago at this point. And I connected an access point to my network and it goes out to the cloud and just finds the controller that exists out in Miraki's space.

7:04So that means that I don't have to deploy anything here. I have to deploy something myself here. I don't have to deploy anything. And either way, the controller and the management functions exist in a cloud space. So both of those might be something we'd consider. Now the other thing is in smaller environments, we might even see this showing up inside of other devices. For example, we could see this embedded either in switches.

7:37Cisco has switches that allow you to embed a wireless LAN controller in there. And then we also have the ability to convert an access point into a very lightweight type of controller, which can be very useful for small locations. I take a bunch of access points that are in an area. I turn one of them into the wireless LAN controller from a functionality perspective. And that way I can manage this very small space without having to purchase a larger than needed wireless LAN controller set of hardware.

8:07And so this is known as the embedded wireless controller, EWC solution when we 're deploying it onto an access point. Now it's worth noting that Cisco actually had two different products and they 're trying to migrate towards one of those. So originally when I talk about the mid-2000s Cisco made an acquisition of a company called Airspace. And previously they had acquired an access point company called Aeronet.

8:41So quite a few different products here that they purchased. And the funny thing about this is that this architecture existed for a very long time. It survived a couple of decades and probably even longer than that. And when we look at these products together this is at this point considered to be a legacy product line. If I were to go out and purchase for example a 5500 controller or an 8500 controller or a 3500, these are the old Aero-S. So running the operating system from Airspace, Aero-S as we called it.

9:16Those are a more legacy product line. And Cisco isn't actively selling these anymore. And the configuration of these was quite different thanks to the underlying operating system. These days Cisco has an iOS Xe platform that they put underneath the catalyst product umbrella. Meaning that we used to refer to catalyst as just switches. Nowadays it can apply to routers and it can apply to access points and it can apply to wireless LAN controllers. For example they have the catalyst 9100 access point line and they have the catalyst 9800 wireless LAN controllers.

9:54And if I want to configure these again they are running iOS Xe. It feels a whole lot like I'm logged into a Cisco switch from a CLI perspective . Whereas the CLI for these legacy products it required studying because it was very different than anything else that Cisco had. Now we mentioned that when we come online the access points are automatically able to discover the wireless LAN controller. So they perform this WLC discovery process.

10:25They're going to start by performing a broadcast to find out if the wireless LAN controller is on the same subnet as me. In larger networks this is rarely the case. Usually the wireless LAN controller lives out in the middle of the network somewhere and we have access points all over the place on all kinds of different subnets. So this is only going to work in lab environments in very small spaces. The most common way that we perform discovery is via DHCP. One of the cool things about migrating to a lightweight architecture back in the day was we were able to leverage DHCP for our access points.

11:02When it was autonomous I had to manually configure all of these access points while I needed to track their IP addresses. With lightweight I can perform DHCP and DHCP by default doesn't include wireless LAN controller information but it can provide lots of other information via options . So I can use DHCP option 43 which is a configuration on pretty much every DHCP server these days. I can tell that server hey you need to pass a particular IP address via this option.

11:35So when I receive the IP address I'm going to receive the IP address and the gateway and the subnet mask and all these things but I'll also receive a wireless LAN controller IP address. So that's the value of using DHCP and again it's the most common option in my experience for locating a wireless LAN controller that's remote. Nesisco does give us a DNS option when we come online we'll get as part of DHCP we're also given DNS servers so if I don't get an IP address via this DHCP process I can instead get the DNS entry or the DNS server rather and then I can perform a name resolution of sysco capwapcontroller.local.

12:23And so this is actually dot local dash domain. So this is an option that we can use if we for whatever reason aren't able to use DHCP option 43 then we can certainly perform this DNS look up. And lastly we can actually perform this as a or perform a manual operation. I can log into the access point I could console into it for example and I could tell it the IP address of the wireless LAN controller.

12:55So regardless we have lots of options and lots of ways for our access points to figure out where in the network the wireless LAN controller is. Now once an access point comes online and performs this discovery it's going to maintain a list of all of the wireless LAN controllers that it becomes aware of. This way when it reloads it doesn't have to go through this discovery process again it can just immediately go out to its list of known controllers and if it can't find a wireless LAN controller maybe that WLC is down it can then perform this discovery process again.

13:33But ideally we only have to do this for initial discovery because for the most part our wireless LAN controller configurations are going to be relatively static and they're not going to be moving around. Now we do have a lot of design considerations to make when it comes to our wireless LAN controllers and that's going to be the focus of this part of this course is to be drilling into the idea of how do we deploy a wireless architecture what is going to be required from a design perspective. I've got to think about things such as licensing to make sure that I have wireless LAN controllers that are large enough and licensed enough for the number of access points in my environment.

14:14So I do need to consider the hardware sizing of my wireless LAN controllers. We have small, medium, large wireless LAN controllers for example we've got to consider failover because if a wireless LAN controller goes down we don't want to lose access to our wireless network. They rely on the wireless LAN controller because the APs are lightweight and they aren't functioning fully on their own. And lastly we mentioned it earlier we do need to worry about the wireless LAN controller location. This is a critical part of a wireless architecture design and we'll talk about the reasons for that here shortly.

14:52[BLANK_AUDIO]

0:00When a lightweight access point comes online, it forms a tunnel to the wireless lane controller. This tunnel is known as the control and provisioning of wireless access points or capwap. Capwap is a very important part of a wireless controller architecture, because what we have is not just a wireless lane controller communicating through the network to an access point. Instead, what we have is we have a tunnel that is built, then we send our management traffic into this tunnel.

0:39But it's not just the management traffic. We also send our wireless client or station traffic in here as well. So it's our management traffic and our data traffic. And so both of these types of traffic will traverse the tunnel through the network to get to the wireless lane controller. Now we might need a quick refresher on what exactly a tunnel architecture is. If we think back to the VXLAN tunnels for our fabric types of architecture, it 's going to be a very similar concept.

1:10The idea is I take an original packet and I encapsulate it further. Normally I'm encapsulating it at layer 3 and layer 2, but then I throw another header in front of this. And this additional tunnel header is going to be what the network is paying attention to. The network doesn't see inside of this packet. So this external tunnel header is saying, "Hey, you know what I'm destined for? The wireless client might be destined out to the internet."

1:42But this tunnel destination is the wireless lane controller IP address. And the source is not the client, the source is the access point IP address. So the underlay, this local area network, whatever this is, a bunch of switches and routers potentially, it's going to look at this destination and source IP address. It has no idea what the client source is as no idea what the internet destination is. Those are inside of the inner packet and those aren't seen.

2:15Once the wireless lane controller receives this packet, it's going to strip off the tunnel header, look at the original packet and it's going to send it on to the network, which funny enough usually involves sending it right back out one of the links that it brought it in on. But in this case, it doesn't have a tunnel header anymore. So the local area network can look at the actual destination and forward it on to wherever it's supposed to be going.

2:46So this creates a lot of interesting conversations around our client traffic. And this brings us back to what we said is important, which is the wireless lane controller location. The reason why the location matters so much, and there's actually quite a few reasons. But one of the main reasons is because the location of the wireless lane controller is where our wireless subnets are going to live, which might seem logical at first that wireless subnets should live where the wireless lane controller is, except before wireless lane controllers existed, these clients were part of whatever local network existed out here. They weren't part of another network. So if I have a site, for example, let's say I have a switched architecture here, I have an SVI and a gateway address for maybe VLAN 10, and this is where my wired clients go. Well, maybe I have another VLAN VLAN 20, and this connects my wireless clients. But either way, both of these subnets

4:02live here on this layer three switch. Well, what did we just do here? We just said that our wireless clients aren't going to live here on this local VLAN 20 subnet, whatever that subnet is. Instead, this 20 subnet will provide an IP address to the access point, but not to the wireless clients. These wireless clients are going to get tunneled through VLAN 20, through the layer three infrastructure, out to wherever the wireless lane controller lives, and this is where the wireless stations are going to pop out.

4:38Tunneling is kind of funny. I like to think of it in terms of SIFI, because in SIFI worlds, like Star Trek, but either way, you see the ability to perform these kind of warps, where you just sort of pop out somewhere. And I can star wars they have that too. I digress, I 'm not sure why we're getting into that conversation. Well, you've got this concept that you sort of disappear and you reappear somewhere else. And it's because you go so fast in the SIFI world that it's like you warp. You just disappear here, reappear here. In networking, that same concept applies, except it has nothing to do with speed. It has everything to do with the fact that the underlying network can't see the information.

5:22It's invisible to the network. And so we still warp the client traffic, which started here, pops up over here. Again, right here, when it shows back up on the network. Up until then, it was hidden inside of that tunnel. It's why we call it a tunnel is because the network can't see inside the tunnel until we pull that traffic outside of it and send it back to the network. So what exactly are we saying here? Why is this matter so much? Well, if we look at the architecture of saying I have a wireless LAN controller here, and this wireless LAN controller is part of a trunk infrastructure. So I'm trunking to a switch and I'm trunking the VLANs 10 and 20 and 30, whatever VLANs I want to trunk over to it. Now I have to have SVIs here for these different VLANs.

6:16So let's say VLAN 30 is a wireless station or wireless client VLAN. So whatever subnet's associated with VLAN 30 here, I'm going to send my traffic through some kind of layer three infrastructure, generally speaking, and I'm going to arrive on the wireless LAN controller. The wireless LAN controller, again, strips out the original packet and sends it down from a layer two perspective into the local network. Well, now this station that's all the way out here at some other location, some other site is now going to be using this SVI as its gateway. It's like it 's attached here from a logical perspective. Because if I am trying to get out to the internet, this station is going to have a destination MAC address of this gateway very far away from where it physically showed up on the network. So this is where the station physically lives. This is where the station logically lives.

7:28And this can be a really bad thing. For example, what if this is inside of my data center? Do I want any of my users to have direct connection into the data center network? No, I would never want my wired stations, let's say, to show up inside of the data center. I wouldn't want a user to be on the same VLAN as my servers or even on the same layer to switch as my servers.

8:01I would want segmentation there. Except doesn't it make sense for us to deploy the wireless line controller in a redundant location such as the data center? So if we decide to deploy the wireless line controller into the data center, now the wireless line controller here is connecting to a data center switch. And therefore the gateway and the subnet and the VLAN and all of these things that live on a data center switch are going to play host to our wireless stations. So this is why we need to pay attention to the wireless line controller location because the wireless subnets are going to exist where the WLC lives. So generally speaking, we don't actually want to deploy it into the data center. It's more common for us to want to deploy it into the distribution layer somewhere out on the network.

8:54But at the same time, this can get tricky because we might have a lot of distribution layers, a distribution block. So which one do we pick? Do we pick all of them? The conversation continues at that point, but this is a foundational concept that we need to understand about the flow of wireless traffic because it will impact where the wireless line controller gets deployed. Now the other reason we have to consider this is because we also need access to the wireless line controller. If an access point is communicating with the wireless line controller and it loses this connection, by default, a lightweight access point will go down because we just said a lot of the intelligence, the management, the configuration, all of the things that it was receiving from the wireless line controller it no longer has. And so the wireless line controller is going to shut down operations and try to find a new wireless line controller using those discovery methods we talked about, which might be possible, but it also might not be possible depending on the situation here. We remote location and the whan link went down. If so, and

10:11there's no local wireless line controller, we're never going to find one, which means that our wireless environment is going to stay down. So we need to maintain access to the wireless line controller, which will again play a role in determining the location so that it's close to our wireless clients in some capacity and also that it's in a redundant location that's unlikely to go down. Now unfortunately, especially for remote locations, we might have a single whan link and survivability can be a concern. Fortunately Cisco does have an option for remote survivability, which is FlexConnect. FlexConnect maintains wireless line controller connectivity, but it does not use the wireless line controller for its data plane operations, meaning it's not going to send data into the tunnels. The data stays local. And as such, we can stay online if the wireless line controller is down. This is a very important part of wireless designs,

11:28because I do not want to lose my wireless LAN necessarily, just because I lose access to the controller. Now for larger infrastructure rich environments like our campus architectures, distribution and access, this isn't a concern, and we would never want to use FlexConnect for a lot of reasons. But as much as anything, Cisco just doesn't support that many FlexConnect access points all at once. We need to be looking at our remote sites for FlexConnect. And ultimately, what we're going to find is that if they do lose access to the wireless line controller, they can stay online, which is very important for us for those remote sites that maybe don't have the best connections back to the network.

0:00There are many different deployment models that we might consider when we are deploying our wireless architecture. And this has to do specifically with, again, the wireless LAN controller location, but it also determines the number of wireless LAN controllers we're going to deploy . So let's just start with the first model, which is the centralized model. In a centralized model, we are ideally going to just deploy a single redundant wireless LAN controller instance.

0:33Now with redundancy, we have two choices. We could deploy two separate wireless LAN controllers and some amount of access points connect to one, some amount of access points connect to the other, and if one of these goes down, then we hope to swing those access points from the first down to the second. There are a lot of challenges with this. For example, if I'm deploying a redundant pair, each of these needs to have not only the hardware, but the licensing for full support. Because if one of them goes down and we don't have the ability to support all of the access points, then it wasn't a very redundant model.

1:09This is more of a legacy type of architecture because it was just what we had to do for a long time. But now Cisco does support the concept of a high availability pair, meaning that I still have to spec out the hardware that's going to be able to support all of the access points. But there's a couple of interesting changes. First of all, I deploy both of these sets of hardware together and then I connect them in a special way so that they are one configuration and ultimately one logical wireless LAN controller.

1:46This fits that conversation we had earlier about Stackwise Virtual, Stackable Switches, Chassis Switches. We're combining two physical components into one logical one, meaning that I only have to configure one. I only have to license one. And at that point, if all of these access points that are connecting to the primary, if the primary fails, then they will automatically switch over to the secondary because it's one configuration. It's using the exact same IP address.

2:17Whereas before, each of these were independent and they each needed their own IP address. So the HA pair is a wonderful way to deploy a centralized model because I can deploy again one logical wireless LAN controller. And I just connect all of the access points into in my entire environment back to this central pair. So, yeah, I guess as we talk about the pros and cons, the pros of this is it's very simple, especially simple to manage.

2:50Management, simple to management, simple to manage. But the cons is the location concept, which is where are we going to deploy this? The previous conversation there, we said that maybe it makes sense to deploy this into the data center, except it doesn't because we don't want the wireless clients living in the data center. So, where are we going to deploy it? Well, I could deploy it into one of my distribution closets, but I might have lots of distribution closets and network blocks in the network.

3:24And so, this works well for the local access points here to connect to the distribution LAN connect. But now all of the access points over here need to come over to this other building in order to access the wireless LAN controller. Does this work? Sure, it does work, but all of the wireless stations out here are now going to belong to subnets that are attached to this distribution layer. So, it centralizes, yeah, the hardware and the management of that hardware and that's great, but also centralizes our wireless subnets.

3:58So, all the wireless subnets in our entire organization now live logically in one location. So, this might lead us to the distributed model. The distributed model is going to flip the centralized model on its head. It's going to allow us to have many wireless LAN controllers and these wireless LAN controllers are going to be smaller because they're only going to service their own sites. So, again, imagine that I have multiple distribution blocks. Maybe I have three different locations.

4:30These are all my distribution locations, so I deploy a HA pair into each one of these distribution layers. Now, the advantage to this is that my access points here can connect up to their local distribution layer to communicate with the wireless LAN controller. Furthermore, all of the wireless stations that are downstream here, all of the stations also attach to subnets that belong to the specific location.

5:02And so, this really fixes a lot of our issues with the logical side of things. For example, the wireless subnets living in a different place and potential latency issues trying to communicate to another location. The downside to this is that I as the admin now have to log in to lots of wireless LAN controllers and manage many configurations. And this can make us as an admin very, very sad because now we have to manage all of these different configs.

5:36The upside to this is that there are software solutions out there, especially in the Cisco world. We can think of Catalyst Center as being an option for us to now manage the software and the software pushes configuration down to all of the controllers for us. But it does, even in that situation, complicate the network a little bit. From a management perspective, we have to manage all of these locations. We also have to individually manage the licensing and the hardware. And, you know, there's upsides and downsides to both models.

6:09We just have to weigh which one we want to really think about. Now on top of all of this, we need to think about our remote sites. Our remote sites usually don't warrant having their own wireless LAN controller on site. For example, I might have a small location that has three access points. What am I going to do about this small site? I've got a switch that has connection to all of these APs.

6:42And this goes through some kind of router and I've got a single wide area network link that takes me back to the rest of the network. Do I need to deploy a very small wireless LAN controller here? Probably not. But I could. I mean, Cisco does make them very small. We could deploy a small wireless LAN controller here. But as we talk about this distributed model, we might already have half a dozen wireless LAN controllers out there. Now I have to deploy one to every one of my remote sites. I could end up with dozens of wireless LAN controllers.

7:13So first and foremost, we could connect out to a remote distribution closet or just our centralized option. If we choose that, connect out to wireless LAN controllers that are remote. We can absolutely do that. It will work just fine until what happens in what we said in the last video happens where the WAN link goes down. This is where we really could use a local wireless LAN controller because then our access points stay online, which might matter if we have a separate internet circuit here that way users can still get out to the internet even if they can't get to the rest of the network.

7:50Now funny enough, that is a conversation because if the internet lives out the WAN link, we could argue that it's not a whole lot of value in maintaining our wireless network at that point. Unless we have wireless phones and we need to make emergency calls, but lots of conversations need to be had around the resiliency level that we're expecting. But if we don't want to deploy wireless LAN controller here, we can take advantage of Cisco Flex Connect, which is typically what we want to do in these locations. Flex Connect, as we said before, allows for us to lose the wide area network and the access points stay online.

8:28Now if we have a very small remote site or maybe more to the point of very small organization, we could technically look at an autonomous solution. This is not the best solution in most cases. Again, each access point has to have its own management and that's not just an IP address, but also radio management. I have to individually manage every channel, the transmit power of every AP. And we said earlier that yeah, this was how we had to do it once upon a time, but really we shouldn't be deploying it today.

9:06So this has a place for very, I'm going to say even very small organizations because if we have an organization with fewer than 10 access points, then it might make sensors deploy it to that or deploy an autonomous solution rather than going with deploying an actual lightweight controller. But we might actually prefer to look at another solution, which can apply to very small and very large deployments and that would be the concept of the cloud.

9:39So we do have cloud managed solutions. And at this point, I'm specifically thinking of something like Cisco's Miracchi product line, which allows me to simply connect an access point to the network. And as long as it can get out to the internet, then it can receive its configuration and it can remain online and all of these things. Now we do not use capwap in this case. So we don't have to worry about our traffic getting tunneled out to wherever the cloud is.

10:15And so it simplifies things that way. I don't even have to worry about the hardware and licensing considerations of a wireless LAN controller. I just purchased one license per AP. I plug the APN, it connects up to the wireless system. And regardless of how many access points I have, I have a single point of management, which makes me as an admin very happy. So the cloud managed solution is actually very popular. Cisco's got both solutions and whether we are trying to figure out what to do with a wireless LAN controller or we just want to go simple and go with cloud managed.

10:55Well, it's just going to depend on the organization of what exactly we're looking for. But either way, we can take a look at all of these different models and try to figure out what the best model is for our organization, not only based on our size, but also based on the current architecture that we have in our environment.

0:00So, as mentioned in the challenge itself, there aren't going to be a lot of wrong answers here. We could probably come up with something that is so outlandish that should never be done. But we want to think back to those deployment models and what we learned about capwap tunnels and lightweight architecture in general and put some thought into where we might put the wireless LAN controllers. And again, I would expect that there could be several valid options here. So let's talk through some of those. So first of all, let's talk about a centralized option.

0:31The centralized option says we're going to deploy a single pair of HA controllers. And we probably want to pick a site that has a lot of access points to be our centralized location. Again, we should never deploy a wireless LAN controller into a layer 3 core. We ideally don't deploy it into a data center, although sometimes it does make the most sense to do so. And so instead, what I would do from an outward design perspective is I would place those controllers here in this distribution block at site 2.

1:03And the reason for that is it has a lot of access points. So that would be a purely centralized model. We would put the wireless LAN controller here. And again, it would be an HA pair. Now the upside to that is it's a single wireless LAN controller I have to manage. The downside is we've got everything from remote sites to WAN sites. So I guess sites connected directly via the core versus sites that have to go through the WAN block.

1:33And a lot of that is going to potentially cause us some problems, at least as far as WAN sites go down and those kinds of things or WAN links go down. Now we could also look at a distributed model. If we look at the distributed model, then that's right there in the name, distribute distribution. We'd probably want to deploy wireless LAN controllers in all three of these distribution blocks. This way the access points only connect locally to a wireless LAN controller.

2:05They also live on subnets that are attached to the actual distribution blocks that are associated with their locations. And then we'd have to figure out what to do about these remote sites, whether they're going to come into, well specifically, this wireless LAN controller or this wireless LAN controller pair. And we could have primary and second areas. So we've got a lot of options there. The downside is I have three different wireless LAN controllers that I have to manage, but three is not too bad. And so that would be a perfectly valid option as well.

2:36Now we could have also suggested we just go with a cloud architecture. This would mean that we have no wireless LAN controllers in the entire environment. Instead the access points are going to connect out through wherever the internet is to connect to the cloud. The downside to that is if our internet goes down or we have problems with that cloud provider, that we might actually see our wireless network impacted. But cloud is a very valid architecture that a lot of organizations rely on.

3:06And again, Cisco does have an architecture for that with their Miracchi platform. Now lastly, we could also consider something special over here with these rem otes. And that would be leveraging FlexConnect. I would argue that in all of these, well maybe not cloud because cloud is a little different, both centralized and distributed models, I would argue that FlexConnect should be used with both of those. Because if I'm centralized here or I'm decentralized either way, there's not a wireless LAN controller out here at the remote sites.

3:44Now if you suggested that we put a small wireless LAN controller out here, that 's probably fine. The four access points, we do have very small controllers for that. Twenty starts to get a little bit larger. We're going to want to explore an HAPAR. And in a lot of cases, it's pretty clear that it doesn't warrant the expense of taking that distributed model and applying that to the remote sites that are out the W AN links. So instead we can find a happy compromise here. Whether it was centralized or distributed, we can then deploy FlexConnect.

4:18And that's going to make sure that our wireless access points stay online in the event of a WAN outage. It also makes it so we don't have to have wireless LAN controllers locally. And even better, the traffic gets dropped off locally, meaning that my wireless client traffic doesn't have to exist on a subnet that belongs to a different location. So as we see here, we alluded to it earlier, the location of the wireless LAN controller matters greatly. And as everything to do with those KAPWF tunnels, as well as just having a redundant, easy to access location, we need to think about whether we're going to deploy a centralized or distributed model.

4:55We need to think about deploying potentially a cloud solution. FlexConnect is a very important part of wireless architecture. And all of this is going to just give us a lot of different things to think about when we're deciding where to deploy wireless LAN controllers, whether we should deploy them at all. And in the end, what are wireless architectures going to look like? I hope this has been informative for you and I'd like to thank you for viewing.