Describe Wireless Architecture

0:00When we think about the management of our wireless networks, things are a

0:05little bit different

0:06than when we're managing our switches and our routers, primarily because of the

0:10sheer

0:10number of access points.

0:13We're talking about wireless communications.

0:15We usually have an access point, which is our network device that maintains a

0:19wired connection

0:20to the switched infrastructure.

0:23And then we're wirelessly communicating to devices that are referred to as

0:28stations.

0:29And abbreviated like so with STA capitalized.

0:33So sometimes I'll refer to these as clients as well, but either way we have

0:37devices that

0:38are wirelessly communicating to these access points.

0:41And I know that back in the day when I was first just very young and entering

0:46into the industry

0:47I was responsible for largely just physical layer things like hanging access

0:52points.

0:53And eventually I learned how to do site surveys.

0:56And I would go into a school and this is like in the mid 2000s and I could do a

1:00wireless

1:01site survey and for the entirety of this building we just need to have six

1:05access points.

1:07And the reason for that was because six access points would get the job done.

1:11We were using 2.4 gigahertz which could go a lot further.

1:15We had lower client density and so we didn't need a lot of AAPs.

1:20And so we might go into a school system and across many different schools maybe

1:24in total

1:25we had 50 or 60 access points.

1:29So still a lot of AAPs but it was at least somewhat manageable to manage every

1:34single AP on its

1:35own.

1:36But even 60 was a lot and as we've had to get into more modern applications and

1:42modern

1:43wireless 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

1:53or 600.

1:55And so we needed a better way even in the mid 2000s and late 2000s to manage

2:01these access

2:02points.

2:03And that led to the creation of the lightweight architecture.

2:11In a lot of ways lightweight wireless was sort of a first step into the world

2:16of software

2:17defined networking.

2:19Because what we did was we said that the amount of intelligence that's required

2:24on this

2:24access point here could be lowered.

2:27I didn't write that very well.

2:29So let's try that again.

2:30We could lower the intelligence level and ultimately the functions of the

2:37software that's

2:38running on this access point.

2:40So it's a more lightweight software image which is where the name comes from.

2:44And then we are connecting back to a wireless LAN controller.

2:50This wireless LAN controller is responsible for maintaining the management of

2:57that device.

2:58And so we could have again lots and lots of access points all communicating

3:02back to the

3:02wireless LAN controller.

3:04And I don't have to manage each one of these access points individually, which

3:08is what

3:08I had to do before a lightweight came around back when it was what we refer to

3:12as an autonomous

3:14architecture.

3:15So lightweight does a lot of good for us and a lot of times it's commonly

3:20centered around

3:21the 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

3:30access point

3:30into the environment, it will automatically find the wireless LAN controller.

3:38And there's a lot of ways that we can help it discover it.

3:40We'll talk about that momentarily.

3:43And the wireless LAN controller is going to push configuration down.

3:47Furthermore, as these access points are nearby each other, we might have one

3:51access point

3:52on channel 40 in the 5 gigahertz space.

3:55And therefore we wouldn't want this wireless or access point to be on channel

4:0040 instead.

4:01The wireless LAN controller would say, all right, we're detecting channel 40 in

4:05the area.

4:06Maybe we're detecting a bunch of other channels.

4:08We think you should deploy on channel 60.

4:12And this might change over time.

4:14But in the end, we're trying to dynamically manage a wireless environment that

4:20isn't static.

4:21Wireless needs change dramatically even within the course of a day.

4:25The amount of interference and the amount of other wireless activities could

4:29prompt us

4:30to change not only the channel, but also the transmit power level.

4:35And so the wireless LAN controller is capable of monitoring the wireless

4:40environment and adjusting

4:42it on an as needed basis.

4:45From a, again, management perspective, me as the admin, I don't have to go out

4:50and manage

4:51all of these access points.

4:52Instead, I manage them all through one device.

4:56That's the wireless LAN controller.

4:59So what exactly is this wireless LAN controller?

5:02Well, for the most part, a wireless LAN controller is going to be a physical

5:08device or appliance

5:10that's going to live on the network somewhere.

5:15And where it lives is very important.

5:16And we'll talk about that later on.

5:19Now they can also take different forms as well these days.

5:22For example, we could deploy it as a virtual appliance.

5:26And a virtual appliance just means that it has to live on one of my virtual

5:30hosts inside

5:31my data center.

5:34We don't often want our wireless LAN controllers to live inside of our data

5:37center.

5:38And so we could deploy this on a virtual host that connects in at a

5:41distribution layer somewhere.

5:43But either way, we could deploy the Cisco makes it available.

5:46First is download the software for a wireless LAN controller.

5:52And rather than purchase an appliance that is a physical set of hardware like

5:57CPU and memory

5:58and all of these things, I can create my own server and deploy the software

6:02onto that.

6:03So that's the concept of deploying it as a virtual appliance.

6:07We can also deploy it into the cloud as a virtual appliance.

6:11Now there's two different aspects to the cloud.

6:14So first of all, I could deploy this concept here, but rather than deploying it

6:19onto my own

6:20physical host, I just deploy the virtual appliance into a cloud space known as

6:27infrastructure

6:28as a service.

6:30It's basically me saying I'm going to spin up a virtual machine in the cloud

6:33and run it

6:34there.

6:35And I could also run this as a controllerless environment.

6:40The best example of this from a Cisco perspective would be Miraki.

6:46Miraki is a product line that originally was a competitor to the Cisco.

6:50Cisco acquired them quite a long time ago at this point.

6:54And I connected an access point to my network and it goes out to the cloud and

6:59just finds

7:00the controller that exists out in Miraki's space.

7:04So that means that I don't have to deploy anything here.

7:06I have to deploy something myself here.

7:09I don't have to deploy anything.

7:11And either way, the controller and the management functions exist in a cloud

7:17space.

7:18So both of those might be something we'd consider.

7:21Now the other thing is in smaller environments, we might even see this showing

7:25up inside of

7:26other devices.

7:28For example, we could see this embedded either in switches.

7:37Cisco has switches that allow you to embed a wireless LAN controller in there.

7:41And then we also have the ability to convert an access point into a very

7:45lightweight type

7:47of controller, which can be very useful for small locations.

7:50I take a bunch of access points that are in an area.

7:53I turn one of them into the wireless LAN controller from a functionality

7:56perspective.

7:57And that way I can manage this very small space without having to purchase a

8:02larger than

8:03needed wireless LAN controller set of hardware.

8:07And so this is known as the embedded wireless controller, EWC solution when we

8:13're deploying

8:14it onto an access point.

8:17Now it's worth noting that Cisco actually had two different products and they

8:23're trying

8:24to migrate towards one of those.

8:26So originally when I talk about the mid-2000s Cisco made an acquisition of a

8:31company called

8:32Airspace.

8:35And previously they had acquired an access point company called Aeronet.

8:41So quite a few different products here that they purchased.

8:45And the funny thing about this is that this architecture existed for a very

8:49long time.

8:50It survived a couple of decades and probably even longer than that.

8:54And when we look at these products together this is at this point considered to

8:59be a legacy

9:00product line.

9:01If I were to go out and purchase for example a 5500 controller or an 8500

9:06controller or

9:07a 3500, these are the old Aero-S.

9:11So running the operating system from Airspace, Aero-S as we called it.

9:16Those are a more legacy product line.

9:19And Cisco isn't actively selling these anymore.

9:22And the configuration of these was quite different thanks to the underlying

9:25operating system.

9:26These days Cisco has an iOS Xe platform that they put underneath the catalyst

9:33product umbrella.

9:35Meaning that we used to refer to catalyst as just switches.

9:39Nowadays it can apply to routers and it can apply to access points and it can

9:43apply to

9:44wireless LAN controllers.

9:45For example they have the catalyst 9100 access point line and they have the

9:50catalyst 9800 wireless

9:52LAN controllers.

9:54And if I want to configure these again they are running iOS Xe.

9:57It feels a whole lot like I'm logged into a Cisco switch from a CLI perspective

10:03.

10:04Whereas the CLI for these legacy products it required studying because it was

10:09very different

10:10than anything else that Cisco had.

10:13Now we mentioned that when we come online the access points are automatically

10:17able to discover

10:19the wireless LAN controller.

10:21So they perform this WLC discovery process.

10:25They're going to start by performing a broadcast to find out if the wireless

10:31LAN controller

10:32is on the same subnet as me.

10:34In larger networks this is rarely the case.

10:36Usually the wireless LAN controller lives out in the middle of the network

10:39somewhere and

10:40we have access points all over the place on all kinds of different subnets.

10:44So this is only going to work in lab environments in very small spaces.

10:49The most common way that we perform discovery is via DHCP.

10:54One of the cool things about migrating to a lightweight architecture back in

10:57the day was

10:58we were able to leverage DHCP for our access points.

11:02When it was autonomous I had to manually configure all of these access points

11:05while I needed

11:06to track their IP addresses.

11:11With lightweight I can perform DHCP and DHCP by default doesn't include

11:17wireless LAN

11:17controller information but it can provide lots of other information via options

11:23.

11:23So I can use DHCP option 43 which is a configuration on pretty much every DHCP

11:29server these days.

11:30I can tell that server hey you need to pass a particular IP address via this

11:35option.

11:35So when I receive the IP address I'm going to receive the IP address and the

11:39gateway and

11:39the subnet mask and all these things but I'll also receive a wireless LAN

11:43controller IP address.

11:45So that's the value of using DHCP and again it's the most common option in my

11:50experience

11:50for locating a wireless LAN controller that's remote.

11:55Nesisco does give us a DNS option when we come online we'll get as part of DHCP

12:01we're

12:01also given DNS servers so if I don't get an IP address via this DHCP process I

12:07can instead

12:08get the DNS entry or the DNS server rather and then I can perform a name

12:13resolution of

12:15sysco capwapcontroller.local.

12:23And so this is actually dot local dash domain.

12:29So this is an option that we can use if we for whatever reason aren't able to

12:33use DHCP

12:34option 43 then we can certainly perform this DNS look up.

12:40And lastly we can actually perform this as a or perform a manual operation.

12:46I can log into the access point I could console into it for example and I could

12:51tell it

12:52the IP address of the wireless LAN controller.

12:55So regardless we have lots of options and lots of ways for our access points to

13:00figure

13:01out where in the network the wireless LAN controller is.

13:04Now once an access point comes online and performs this discovery it's going to

13:10maintain

13:11a list of all of the wireless LAN controllers that it becomes aware of.

13:18This way when it reloads it doesn't have to go through this discovery process

13:21again it

13:22can just immediately go out to its list of known controllers and if it can't

13:26find a wireless

13:27LAN controller maybe that WLC is down it can then perform this discovery

13:32process again.

13:33But ideally we only have to do this for initial discovery because for the most

13:36part our wireless

13:37LAN controller configurations are going to be relatively static and they're not

13:41going

13:41to be moving around.

13:43Now we do have a lot of design considerations to make when it comes to our

13:49wireless LAN

13:50controllers and that's going to be the focus of this part of this course is to

13:54be drilling

13:55into the idea of how do we deploy a wireless architecture what is going to be

14:00required from

14:01a design perspective.

14:02I've got to think about things such as licensing to make sure that I have

14:08wireless LAN controllers

14:09that are large enough and licensed enough for the number of access points in my

14:13environment.

14:14So I do need to consider the hardware sizing of my wireless LAN controllers.

14:19We have small, medium, large wireless LAN controllers for example we've got to

14:24consider failover

14:25because if a wireless LAN controller goes down we don't want to lose access to

14:30our wireless

14:31network.

14:32They rely on the wireless LAN controller because the APs are lightweight and

14:36they aren't functioning

14:37fully on their own.

14:39And lastly we mentioned it earlier we do need to worry about the wireless LAN

14:43controller

14:43location. This is a critical part of a wireless architecture design and we'll

14:50talk about the

14:51reasons for that here shortly.

14:52[BLANK_AUDIO]

0:00When a lightweight access point comes online, it forms a tunnel to the wireless

0:04lane controller.

0:05This tunnel is known as the control and provisioning of wireless access points

0:10or capwap.

0:12Capwap is a very important part of a wireless controller architecture,

0:18because what we have is not just a wireless lane controller communicating

0:23through the network to an access point.

0:29Instead, what we have is we have a tunnel that is built, then we send our

0:36management traffic into this tunnel.

0:39But it's not just the management traffic.

0:41We also send our wireless client or station traffic in here as well.

0:47So it's our management traffic and our data traffic.

0:51And so both of these types of traffic will traverse the tunnel through the

0:55network to get to the wireless lane controller.

0:58Now we might need a quick refresher on what exactly a tunnel architecture is.

1:03If we think back to the VXLAN tunnels for our fabric types of architecture, it

1:08's going to be a very similar concept.

1:10The idea is I take an original packet and I encapsulate it further.

1:16Normally I'm encapsulating it at layer 3 and layer 2, but then I throw another

1:21header in front of this.

1:23And this additional tunnel header is going to be what the network is paying

1:27attention to.

1:29The network doesn't see inside of this packet.

1:33So this external tunnel header is saying, "Hey, you know what I'm destined for?

1:38The wireless client might be destined out to the internet."

1:42But this tunnel destination is the wireless lane controller IP address.

1:47And the source is not the client, the source is the access point IP address.

1:53So the underlay, this local area network, whatever this is, a bunch of switches

1:59and routers potentially,

2:01it's going to look at this destination and source IP address.

2:04It has no idea what the client source is as no idea what the internet

2:08destination is.

2:09Those 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

2:20the tunnel header,

2:23look at the original packet and it's going to send it on to the network,

2:29which funny enough usually involves sending it right back out one of the links

2:34that it brought it in on.

2:35But in this case, it doesn't have a tunnel header anymore.

2:39So the local area network can look at the actual destination and forward it on

2:44to wherever it's supposed to be going.

2:46So this creates a lot of interesting conversations around our client traffic.

2:55And this brings us back to what we said is important, which is the wireless

2:59lane controller location.

3:01The reason why the location matters so much, and there's actually quite a few

3:06reasons.

3:07But one of the main reasons is because the location of the wireless lane

3:11controller

3:12is where our wireless subnets are going to live,

3:17which might seem logical at first that wireless subnets should live where the

3:23wireless lane controller is,

3:25except before wireless lane controllers existed, these clients were part of

3:30whatever local network

3:32existed out here. They weren't part of another network. So if I have a site,

3:38for example,

3:39let's say I have a switched architecture here, I have an SVI and a gateway

3:45address for maybe VLAN 10,

3:48and this is where my wired clients go. Well, maybe I have another VLAN VLAN 20,

3:54and this connects my wireless clients. But either way, both of these subnets

4:02live here on this layer

4:04three switch. Well, what did we just do here? We just said that our wireless

4:09clients aren't going to

4:10live here on this local VLAN 20 subnet, whatever that subnet is. Instead, this

4:1620 subnet will provide an

4:18IP address to the access point, but not to the wireless clients. These wireless

4:24clients are going to

4:26get tunneled through VLAN 20, through the layer three infrastructure, out to

4:31wherever the wireless

4:33lane controller lives, and this is where the wireless stations are going to pop

4:38out.

4:38Tunneling is kind of funny. I like to think of it in terms of SIFI, because in

4:43SIFI worlds,

4:44like Star Trek, but either way, you see the ability to perform these kind of

4:50warps, where you just

4:52sort of pop out somewhere. And I can star wars they have that too. I digress, I

4:56'm not sure why we're

4:57getting into that conversation. Well, you've got this concept that you sort of

5:02disappear and you reappear

5:03somewhere else. And it's because you go so fast in the SIFI world that it's

5:08like you warp. You just

5:10disappear here, reappear here. In networking, that same concept applies, except

5:14it has nothing to do

5:15with speed. It has everything to do with the fact that the underlying network

5:20can't see the information.

5:22It's invisible to the network. And so we still warp the client traffic, which

5:27started here,

5:28pops up over here. Again, right here, when it shows back up on the network. Up

5:34until then,

5:35it was hidden inside of that tunnel. It's why we call it a tunnel is because

5:39the network can't see

5:40inside the tunnel until we pull that traffic outside of it and send it back to

5:44the network.

5:45So what exactly are we saying here? Why is this matter so much? Well, if we

5:51look at the architecture

5:53of saying I have a wireless LAN controller here, and this wireless LAN

5:57controller is part of a

5:59trunk infrastructure. So I'm trunking to a switch and I'm trunking the VLANs 10

6:06and 20 and 30,

6:08whatever VLANs I want to trunk over to it. Now I have to have SVIs here for

6:14these different VLANs.

6:16So let's say VLAN 30 is a wireless station or wireless client VLAN. So whatever

6:23subnet's associated

6:24with VLAN 30 here, I'm going to send my traffic through some kind of layer

6:31three infrastructure,

6:33generally speaking, and I'm going to arrive on the wireless LAN controller. The

6:38wireless LAN

6:39controller, again, strips out the original packet and sends it down from a

6:45layer two perspective

6:46into the local network. Well, now this station that's all the way out here at

6:54some other location,

6:56some other site is now going to be using this SVI as its gateway. It's like it

7:02's attached here

7:04from a logical perspective. Because if I am trying to get out to the internet,

7:10this station is going to

7:11have a destination MAC address of this gateway very far away from where it

7:18physically showed up on

7:21the network. So this is where the station physically lives. This is where the

7:26station logically lives.

7:28And this can be a really bad thing. For example, what if this is inside of my

7:36data center?

7:37Do I want any of my users to have direct connection into the data center

7:44network? No, I would never want my

7:48wired stations, let's say, to show up inside of the data center. I wouldn't

7:53want a user to be on

7:55the same VLAN as my servers or even on the same layer to switch as my servers.

8:01I would want segmentation

8:02there. Except doesn't it make sense for us to deploy the wireless line

8:07controller in a redundant

8:09location such as the data center? So if we decide to deploy the wireless line

8:13controller into the

8:14data center, now the wireless line controller here is connecting to a data

8:19center switch.

8:20And therefore the gateway and the subnet and the VLAN and all of these things

8:26that live on a data

8:27center switch are going to play host to our wireless stations. So this is why

8:34we need to pay attention

8:36to the wireless line controller location because the wireless subnets are going

8:40to exist where the

8:41WLC lives. So generally speaking, we don't actually want to deploy it into the

8:46data center. It's more

8:48common for us to want to deploy it into the distribution layer somewhere out on

8:52the network.

8:54But at the same time, this can get tricky because we might have a lot of

8:58distribution layers,

8:59a distribution block. So which one do we pick? Do we pick all of them? The

9:04conversation continues

9:05at that point, but this is a foundational concept that we need to understand

9:09about the flow of

9:12wireless traffic because it will impact where the wireless line controller gets

9:17deployed.

9:18Now the other reason we have to consider this is because we also need access to

9:26the wireless

9:27line controller. If an access point is communicating with the wireless line

9:32controller and it loses

9:34this connection, by default, a lightweight access point will go down because we

9:41just said a lot of

9:42the intelligence, the management, the configuration, all of the things that it

9:47was receiving from the

9:48wireless line controller it no longer has. And so the wireless line controller

9:53is going to

9:54shut down operations and try to find a new wireless line controller using those

10:01discovery methods

10:01we talked about, which might be possible, but it also might not be possible

10:05depending on

10:06the situation here. We remote location and the whan link went down. If so, and

10:11there's no

10:12local wireless line controller, we're never going to find one, which means that

10:16our wireless

10:17environment is going to stay down. So we need to maintain access to the

10:21wireless line controller,

10:22which will again play a role in determining the location so that it's close to

10:28our wireless

10:28clients in some capacity and also that it's in a redundant location that's

10:33unlikely to go down.

10:34Now unfortunately, especially for remote locations, we might have a single whan

10:40link and

10:41survivability can be a concern. Fortunately Cisco does have an option for

10:48remote survivability,

10:50which is FlexConnect. FlexConnect maintains wireless line controller

10:59connectivity,

10:59but it does not use the wireless line controller for its data plane operations,

11:08meaning it's not

11:09going to send data into the tunnels. The data stays local. And as such, we can

11:17stay online

11:18if the wireless line controller is down. This is a very important part of

11:26wireless designs,

11:28because I do not want to lose my wireless LAN necessarily, just because I lose

11:33access to the controller.

11:35Now for larger infrastructure rich environments like our campus architectures,

11:42distribution and

11:43access, this isn't a concern, and we would never want to use FlexConnect for a

11:48lot of reasons. But

11:50as much as anything, Cisco just doesn't support that many FlexConnect access

11:54points all at once.

11:55We need to be looking at our remote sites for FlexConnect. And ultimately, what

12:01we're going to find

12:02is that if they do lose access to the wireless line controller, they can stay

12:06online, which is very

12:08important for us for those remote sites that maybe don't have the best

12:12connections back to the network.

0:00There are many different deployment models that we might consider when we are

0:05deploying

0:05our wireless architecture.

0:07And this has to do specifically with, again, the wireless LAN controller

0:12location, but

0:12it also determines the number of wireless LAN controllers we're going to deploy

0:19.

0:19So let's just start with the first model, which is the centralized model.

0:25In a centralized model, we are ideally going to just deploy a single redundant

0:30wireless

0:31LAN controller instance.

0:33Now with redundancy, we have two choices.

0:37We could deploy two separate wireless LAN controllers and some amount of access

0:40points

0:41connect to one, some amount of access points connect to the other, and if one

0:44of these

0:45goes down, then we hope to swing those access points from the first down to the

0:49second.

0:50There are a lot of challenges with this.

0:51For example, if I'm deploying a redundant pair, each of these needs to have not

0:56only the

0:56hardware, but the licensing for full support.

1:01Because if one of them goes down and we don't have the ability to support all

1:05of the access

1:06points, 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

1:14to do for a

1:14long time.

1:16But now Cisco does support the concept of a high availability pair, meaning

1:22that I still

1:23have to spec out the hardware that's going to be able to support all of the

1:27access points.

1:29But there's a couple of interesting changes.

1:30First of all, I deploy both of these sets of hardware together and then I

1:35connect them

1:36in a special way so that they are one configuration and ultimately one logical

1:45wireless LAN controller.

1:46This fits that conversation we had earlier about Stackwise Virtual, Stackable

1:51Switches, Chassis

1:53Switches.

1:54We're combining two physical components into one logical one, meaning that I

1:58only have

1:58to configure one.

2:00I only have to license one.

2:02And at that point, if all of these access points that are connecting to the

2:07primary, if

2:08the primary fails, then they will automatically switch over to the secondary

2:12because it's

2:13one configuration.

2:14It's using the exact same IP address.

2:17Whereas before, each of these were independent and they each needed their own

2:21IP address.

2:22So the HA pair is a wonderful way to deploy a centralized model because I can

2:26deploy again

2:28one logical wireless LAN controller.

2:32And I just connect all of the access points into in my entire environment back

2:37to this

2:38central pair.

2:39So, yeah, I guess as we talk about the pros and cons, the pros of this is it's

2:46very simple,

2:47especially simple to manage.

2:50Management, simple to management, simple to manage.

2:54But the cons is the location concept, which is where are we going to deploy

3:01this?

3:02The previous conversation there, we said that maybe it makes sense to deploy

3:07this into

3:08the data center, except it doesn't because we don't want the wireless clients

3:11living in

3:12the data center.

3:13So, where are we going to deploy it?

3:15Well, I could deploy it into one of my distribution closets, but I might have

3:19lots of distribution

3:21closets and network blocks in the network.

3:24And so, this works well for the local access points here to connect to the

3:28distribution

3:29LAN connect.

3:30But now all of the access points over here need to come over to this other

3:34building in

3:35order to access the wireless LAN controller.

3:38Does this work?

3:39Sure, it does work, but all of the wireless stations out here are now going to

3:44belong to

3:44subnets that are attached to this distribution layer.

3:48So, it centralizes, yeah, the hardware and the management of that hardware and

3:53that's

3:53great, but also centralizes our wireless subnets.

3:58So, all the wireless subnets in our entire organization now live logically in

4:04one location.

4:05So, this might lead us to the distributed model.

4:10The distributed model is going to flip the centralized model on its head.

4:14It's going to allow us to have many wireless LAN controllers and these wireless

4:18LAN controllers

4:19are going to be smaller because they're only going to service their own sites.

4:24So, again, imagine that I have multiple distribution blocks.

4:28Maybe I have three different locations.

4:30These are all my distribution locations, so I deploy a HA pair into each one of

4:36these

4:37distribution layers.

4:39Now, the advantage to this is that my access points here can connect up to

4:46their local distribution

4:47layer to communicate with the wireless LAN controller.

4:51Furthermore, all of the wireless stations that are downstream here, all of the

4:55stations

4:56also 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.

5:07For example, the wireless subnets living in a different place and potential

5:12latency

5:12issues trying to communicate to another location.

5:15The downside to this is that I as the admin now have to log in to lots of

5:21wireless LAN

5:22controllers and manage many configurations.

5:28And this can make us as an admin very, very sad because now we have to manage

5:33all of these

5:34different configs.

5:36The upside to this is that there are software solutions out there, especially

5:40in the Cisco

5:41world.

5:42We can think of Catalyst Center as being an option for us to now manage the

5:47software and the

5:48software pushes configuration down to all of the controllers for us.

5:53But it does, even in that situation, complicate the network a little bit.

5:58From a management perspective, we have to manage all of these locations.

6:01We also have to individually manage the licensing and the hardware.

6:05And, you know, there's upsides and downsides to both models.

6:09We just have to weigh which one we want to really think about.

6:14Now on top of all of this, we need to think about our remote sites.

6:20Our remote sites usually don't warrant having their own wireless LAN controller

6:25on site.

6:26For example, I might have a small location that has three access points.

6:34What am I going to do about this small site?

6:37I'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

6:46network link that

6:47takes me back to the rest of the network.

6:50Do I need to deploy a very small wireless LAN controller here?

6:53Probably not.

6:54But I could.

6:55I mean, Cisco does make them very small.

6:57We could deploy a small wireless LAN controller here.

7:00But as we talk about this distributed model, we might already have half a dozen

7:05wireless

7:05LAN controllers out there.

7:07Now I have to deploy one to every one of my remote sites.

7:10I could end up with dozens of wireless LAN controllers.

7:13So first and foremost, we could connect out to a remote distribution closet or

7:18just our

7:19centralized option.

7:21If we choose that, connect out to wireless LAN controllers that are remote.

7:25We can absolutely do that.

7:27It will work just fine until what happens in what we said in the last video

7:32happens where

7:33the WAN link goes down.

7:34This is where we really could use a local wireless LAN controller because then

7:39our access

7:39points stay online, which might matter if we have a separate internet circuit

7:45here that

7:45way users can still get out to the internet even if they can't get to the rest

7:49of the network.

7:50Now funny enough, that is a conversation because if the internet lives out the

7:55WAN link, we

7:55could argue that it's not a whole lot of value in maintaining our wireless

7:59network at that

8:00point.

8:02Unless we have wireless phones and we need to make emergency calls, but lots of

8:05conversations

8:06need to be had around the resiliency level that we're expecting.

8:10But if we don't want to deploy wireless LAN controller here, we can take

8:14advantage of

8:15Cisco Flex Connect, which is typically what we want to do in these locations.

8:20Flex Connect, as we said before, allows for us to lose the wide area network

8:25and the access

8:26points stay online.

8:28Now if we have a very small remote site or maybe more to the point of very

8:34small organization,

8:35we could technically look at an autonomous solution.

8:39This is not the best solution in most cases.

8:43Again, each access point has to have its own management and that's not just an

8:49IP address,

8:50but also radio management.

8:51I have to individually manage every channel, the transmit power of every AP.

8:58And we said earlier that yeah, this was how we had to do it once upon a time,

9:03but really

9:04we shouldn't be deploying it today.

9:06So this has a place for very, I'm going to say even very small organizations

9:13because if we

9:14have an organization with fewer than 10 access points, then it might make

9:18sensors deploy

9:18it to that or deploy an autonomous solution rather than going with deploying an

9:25actual

9:26lightweight controller.

9:27But we might actually prefer to look at another solution, which can apply to

9:31very small

9:32and very large deployments and that would be the concept of the cloud.

9:39So we do have cloud managed solutions.

9:44And at this point, I'm specifically thinking of something like Cisco's Miracchi

9:48product line,

9:50which allows me to simply connect an access point to the network.

9:54And as long as it can get out to the internet, then it can receive its

9:59configuration and it

10:01can remain online and all of these things.

10:06Now we do not use capwap in this case.

10:09So we don't have to worry about our traffic getting tunneled out to wherever

10:13the cloud is.

10:15And so it simplifies things that way.

10:17I don't even have to worry about the hardware and licensing considerations of a

10:22wireless

10:23LAN controller.

10:24I just purchased one license per AP.

10:27I plug the APN, it connects up to the wireless system.

10:32And regardless of how many access points I have, I have a single point of

10:36management,

10:37which makes me as an admin very happy.

10:41So the cloud managed solution is actually very popular.

10:45Cisco's got both solutions and whether we are trying to figure out what to do

10:50with a wireless

10:50LAN 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

10:59looking for.

11:00But either way, we can take a look at all of these different models and try to

11:04figure out

11:05what the best model is for our organization, not only based on our size, but

11:10also based

11:10on 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

0:04wrong answers

0:05here.

0:06We could probably come up with something that is so outlandish that should

0:09never be done.

0:10But we want to think back to those deployment models and what we learned about

0:13capwap tunnels

0:14and lightweight architecture in general and put some thought into where we

0:18might put the

0:19wireless LAN controllers.

0:21And again, I would expect that there could be several valid options here.

0:24So let's talk through some of those.

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

0:36controllers.

0:37And we probably want to pick a site that has a lot of access points to be our

0:41centralized

0:41location.

0:42Again, we should never deploy a wireless LAN controller into a layer 3 core.

0:47We ideally don't deploy it into a data center, although sometimes it does make

0:50the most

0:51sense to do so.

0:52And so instead, what I would do from an outward design perspective is I would

0:57place those

0:58controllers here in this distribution block at site 2.

1:03And the reason for that is it has a lot of access points.

1:07So that would be a purely centralized model.

1:10We would put the wireless LAN controller here.

1:13And again, it would be an HA pair.

1:16Now the upside to that is it's a single wireless LAN controller I have to

1:19manage.

1:20The downside is we've got everything from remote sites to WAN sites.

1:26So I guess sites connected directly via the core versus sites that have to go

1:31through

1:32the WAN block.

1:33And a lot of that is going to potentially cause us some problems, at least as

1:38far as WAN

1:39sites go down and those kinds of things or WAN links go down.

1:43Now we could also look at a distributed model.

1:47If we look at the distributed model, then that's right there in the name,

1:51distribute distribution.

1:53We'd probably want to deploy wireless LAN controllers in all three of these

1:57distribution

1:58blocks.

2:00This 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

2:10that are

2:10associated with their locations.

2:13And then we'd have to figure out what to do about these remote sites, whether

2:15they're

2:15going to come into, well specifically, this wireless LAN controller or this

2:20wireless LAN controller

2:21pair.

2:22And we could have primary and second areas.

2:24So we've got a lot of options there.

2:27The downside is I have three different wireless LAN controllers that I have to

2:30manage, but

2:31three is not too bad.

2:33And so that would be a perfectly valid option as well.

2:36Now we could have also suggested we just go with a cloud architecture.

2:41This would mean that we have no wireless LAN controllers in the entire

2:45environment.

2:46Instead the access points are going to connect out through wherever the

2:49internet is to connect

2:50to the cloud.

2:52The downside to that is if our internet goes down or we have problems with that

2:57cloud provider,

2:58that we might actually see our wireless network impacted.

3:01But 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

3:12platform.

3:13Now lastly, we could also consider something special over here with these rem

3:19otes.

3:19And that would be leveraging FlexConnect.

3:23I would argue that in all of these, well maybe not cloud because cloud is a

3:27little different,

3:28both centralized and distributed models, I would argue that FlexConnect should

3:32be used

3:34with both of those.

3:36Because if I'm centralized here or I'm decentralized either way, there's not a

3:41wireless LAN controller

3:42out here at the remote sites.

3:44Now if you suggested that we put a small wireless LAN controller out here, that

3:47's probably fine.

3:49The four access points, we do have very small controllers for that.

3:53Twenty starts to get a little bit larger.

3:55We're going to want to explore an HAPAR.

3:58And in a lot of cases, it's pretty clear that it doesn't warrant the expense of

4:04taking

4:05that distributed model and applying that to the remote sites that are out the W

4:09AN links.

4:10So instead we can find a happy compromise here.

4:12Whether 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

4:21the event of a

4:22WAN outage.

4:23It also makes it so we don't have to have wireless LAN controllers locally.

4:27And even better, the traffic gets dropped off locally, meaning that my wireless

4:32client

4:32traffic doesn't have to exist on a subnet that belongs to a different location.

4:38So as we see here, we alluded to it earlier, the location of the wireless LAN

4:41controller

4:42matters greatly.

4:43And as everything to do with those KAPWF tunnels, as well as just having a

4:48redundant, easy to

4:49access location, we need to think about whether we're going to deploy a

4:52centralized or distributed

4:54model.

4:55We need to think about deploying potentially a cloud solution.

4:58FlexConnect is a very important part of wireless architecture.

5:01And all of this is going to just give us a lot of different things to think

5:06about when

5:07we're deciding where to deploy wireless LAN controllers, whether we should

5:10deploy them

5:10at all.

5:11And in the end, what are wireless architectures going to look like?

5:15I hope this has been informative for you and I'd like to thank you for viewing.