Define Wireless Network Architectures

0:00[AUDIO LOGO]

0:05Welcome to define wireless network architectures.

0:08As we move into domain 2 of the CWDP blueprint,

0:11it is time for us to get more technical.

0:14And so in this video series, we're

0:15going to be talking about wireless network architectures,

0:18such as the original autonomous access

0:21points that we used to deploy a long time ago,

0:23and certainly we could still find low-end solutions today

0:26that leverage that architecture.

0:27But for the most part, we are going

0:29to be focusing in on cloud and lightweight architectures that

0:33involve wireless LAN controllers.

0:35Whether it's cloud or wireless LAN controller base,

0:38it's going to be what we call a lightweight architecture.

0:40Our access points are not going to be very useful,

0:43unless they connect to some kind of centrally managed system.

0:46Ultimately, what we're talking about here

0:47is we more so with wireless than with other technologies,

0:51we have so many devices to manage.

0:54With wireless or maybe I should say with local area network

0:58type of deals, we're talking about access layer switches,

1:01core switches, distribution switches,

1:02we can wrap our arms around that.

1:04There's not nearly as many switches in our infrastructure

1:07as we have wireless access points,

1:10because we could have dozens, if not hundreds,

1:12at every single one of our locations.

1:14And some enterprise organizations

1:15might find that they have thousands or tens of thousands

1:18of access points.

1:20But managing each one individually

1:21is not going to scale particularly well.

1:24And so this is why we introduce the lightweight architecture

1:27to say OK, now our access points are all managed centrally

1:31by some kind of controller system, whether again,

1:34that's cloud or a wireless LAN controller that's doing it.

1:37And so once we understand that architecture,

1:40we can then start to look at some of the ramifications

1:42of that architecture.

1:44Especially when we have wireless LAN controllers,

1:46we have this concept of CAPWAP tunneling.

1:48The concept of a network tunnel basically

1:50says if I am physically in this part of the network, that's

1:54great, except I'm going to tunnel

1:55that traffic to a different part of the network.

1:57And then as far as the rest of the network is concerned,

2:00that's actually where I am.

2:01So we'd call that my logical point of presence

2:03versus my physical point of presence.

2:05And so we're going to learn this concept of tunneling,

2:07and understand how it can benefit us in a wireless LAN

2:11controller architecture.

2:12We're going to also talk a little bit about the concept

2:14of wireless bridging.

2:16Wireless bridging is the idea that I

2:18can extend my network between two sites using

2:21a wireless connection.

2:22And so this is wonderful.

2:24If I've got a site that is down the street

2:26or within line of sight, then I don't need to bury fiber.

2:31I don't need to do anything expensive.

2:33I can simply buy a couple of wireless radios,

2:35and point them at each other.

2:37And I can connect my network that way.

2:38But there are definitely some things

2:40we're going to want to take into account when

2:42we're planning to install wireless bridge links.

2:44So we're going to again get a little bit more technical

2:47as we start to unpack the different types

2:49of wireless architectures that exist

2:51and the ones that we might end up recommending

2:53as part of our designs.

2:54So with that, let's dive in.

2:55I'll see you in the next video.

0:00[AUDIO LOGO]

0:05Let's kick off our conversation by talking

0:07about where we came from, which is the idea of autonomous

0:10access points.

0:11Autonomous access points where we

0:12talked about where every access point needs

0:14to be configured individually.

0:16And so that doesn't scale particularly well.

0:18And so we came up with this lightweight architecture.

0:20And one of the ways we can manage

0:22the lightweight architecture is with a cloud-managed solution.

0:25So let's go and take a look at these two concepts

0:28before we dive into what life looks like with wireless LAN

0:31controllers coming up.

0:32When you look at the start of our wireless architectures,

0:34we all began with the concept of autonomous access points.

0:38And eventually, the wireless world evolved its practice

0:41and deployed something that we call

0:43a lightweight architecture.

0:45Now this lightweight architecture

0:46originally started with wireless LAN controllers.

0:49And wireless LAN controllers really

0:51are a very different type of animal.

0:53We still have them in a lot of architectures today.

0:55And so we're going to talk about that in the next video.

0:57But what we've seen as well coming

1:00from the lightweight architecture,

1:01is the ability to run a lightweight architecture using

1:04a cloud management solution.

1:07And so we've got a lot of vendors

1:09that support cloud management.

1:10And there are advantages and disadvantages to that.

1:13And so in this video, we want to focus

1:15a little bit on the autonomous world

1:17as well as the cloud-managed world

1:18because it doesn't change our underlying network

1:21architecture, whether we're running

1:22autonomous or cloud-managed, it only

1:24changes the way we manage things.

1:26Whereas a lightweight architecture

1:27running a wireless LAN controller, that truly does

1:30change the way our networks work.

1:32So how exactly did the autonomous solution work?

1:35It has been a while since we've really relied on this.

1:38Wireless was developed in the late '90s, believe it or not,

1:41it's been around that long.

1:42And we used autonomous all the way through, I would say,

1:45the mid-2000s.

1:46It was around the mid-2000s that the lightweight architecture

1:49first showed up.

1:50And so during this time, our access points

1:53were treated pretty much like any other network device.

1:56Any network device that sits on our network even today,

1:59for the most part, we're logging in

2:01and we are doing a manual configuration.

2:04This configuration is typically done

2:05via CLI or possibly some kind of graphical user interface,

2:09usually through our web browser.

2:11And so we were configuring each individual access point.

2:13We also had to upgrade and manage

2:16the software for every single access point.

2:18And one of the reasons why I absolutely love wireless

2:21is because this is where I got my start in the industry.

2:24I was originally hired to basically mount access points

2:27and learn how to configure them.

2:29And so during this time frame, I remember

2:32pulling out dozens of boxes for a wireless install.

2:35And I'd pull all the access points out,

2:36and I'd stack them all up on my desk.

2:38And I really had a good process down

2:40for this, a good process for mid-2000s, I suppose.

2:44And I had all of my access points lined up and stacked.

2:47And I would move my console port through each one of the access

2:51points.

2:51I had I think three or four power cables,

2:53so I would power four of them up at a time.

2:55I'd configure one, move the power cord

2:58from the first access point to the fifth,

3:00so it could start powering up.

3:02And then I'd move my console cord to the next one,

3:05and start configuring it.

3:06And so the reality is that if I had a wireless deployment

3:10with 200 access points, which wasn't at all uncommon,

3:13I would spend about three days just configuring all 200

3:17of those access points.

3:18Because each one needed to be manually configured.

3:21And it took a little bit.

3:23I mean half of the wait time was just

3:25the process of powering on access points

3:27and moving the console cable across.

3:29And so this was, as you can imagine,

3:32not an ideal situation.

3:34It's one thing to say, OK, I'm going

3:36to install a bunch of switches, but even a bunch of switches,

3:40I mean, maybe 20 switches in a large deployment.

3:43And a lot of cases, maybe two or three

3:45switches for every dozen or two dozen access points.

3:49And so access points had a scaling problem

3:52where the rest of the network did not.

3:54And it's not just a matter of configuring and upgrading

3:56but also the fact that we had to manage the access points.

4:00We think about all of the things that our wireless systems

4:02do for us these days.

4:04For example, we'd have to tune the radios manually.

4:08If one of the radios was turned up too much,

4:10I'd have to log into that access point,

4:11and I'd have to turn that radio down.

4:13I'd have to select channels, so the channel assignment

4:16was a manual process.

4:18I needed to make sure that if I was going to deploy 200 access

4:22points, that I had all of the channels figured

4:24out and properly labeled on the access point,

4:26so they could be installed into the correct places based

4:28on that channel scheme.

4:29Now in fairness, some vendors did have a management solution

4:33that would do this for us, but this

4:35was not what we'd consider to be one of our modern management

4:38systems.

4:39They would basically log into these access points,

4:41it would perform CLI commands.

4:43And sometimes this would work well,

4:45and sometimes it wouldn't.

4:46And so we never really knew what we

4:48were getting by deploying one of these vendor-based management

4:51solutions.

4:52And just to make things more complex, by the way,

4:54because of all of the manual logging in and performing CLI

4:57commands, whether that was a management solution

5:00or whether that was us, we really

5:02had to rely on static IP addresses,

5:05because if I was going to log into a specific access point

5:08and change a specific radio or a specific channel,

5:11I had to know what access point I was logging into.

5:14And so I'd have to not only use static IPs,

5:16but I would have to document those static IPs so

5:20that when I looked at a diagram or maybe a spreadsheet,

5:22I could find the access point, I could get the IP

5:25address from that document, and then

5:26I could log into it that way.

5:28So as you can see, we had some problems

5:30that we needed to resolve.

5:31And this is where the lightweight architecture

5:33came into existence.

5:35The concept of the lightweight architecture

5:37was basically to do what this management solution down here

5:41was trying to do, but to do it in a much better way.

5:44One of the ways we did this, was we offloaded

5:47a lot of the configuration, meaning

5:49that the configuration is no longer managed by the access

5:52point itself, but is managed by, once again, a wireless

5:56LAN controller.

5:57At the time we didn't have cloud-managed solutions,

5:59and so we had to install a physical wireless LAN

6:02controller somewhere in the architecture.

6:04Now because this configuration was offloaded,

6:07this meant that a lightweight access

6:08point that couldn't find a wireless LAN

6:11controller basically meant that it was dead in the water.

6:14It wasn't able to do anything without connection

6:17to the wireless LAN controller.

6:18So we need to make sure these wireless LAN controllers stayed

6:21up, otherwise we'd lose our entire wireless domain.

6:24So the idea here is the lightweight access point

6:26would boot up, it would find the wireless LAN controller,

6:29it would download the configuration,

6:32it could even download the appropriate version of code

6:34that it's supposed to be running.

6:36And so there's a lot of advantages

6:37right away right here.

6:38But then the wireless LAN controller

6:40would continue to manage that access point as well.

6:44It would do things like tune the radios.

6:46It would decide which channel it should

6:49use based on interference.

6:50And so look at all the things I didn't

6:52have to think about anymore.

6:53I didn't have to worry about manual assignment of channels,

6:56I didn't have to worry about manually doing a whole,

6:58I didn't have to configure access points out of the box.

7:01I could simply plug them into the network.

7:03And importantly, we could rely on DHCP for this.

7:07I didn't have to worry about my static IP tracking anymore.

7:11And the reason for this is because me as the admin,

7:13I no longer log in to the access point.

7:16This doesn't happen anymore.

7:18Instead, I log into the wireless LAN controller,

7:21and so this needs a static IP.

7:23But then the wireless LAN controller

7:25is going to again push all of the configuration down

7:27to the access points, and it's going to track those for me,

7:30meaning that I don't care anymore what IP

7:33address the access points have.

7:35The wireless LAN controller will keep track of that,

7:37and it will keep track of that based on the fact

7:39that the access points are logging in to the wireless LAN

7:42controller when they boot.

7:43Doesn't matter what the IP address is at that point.

7:46And so this is why we can rely on DHCP.

7:48Now the other interesting thing about lightweight wireless

7:51LAN controller architectures is this concept of tunneling.

7:54And we'll go into a little more details

7:56about what that means coming up in the next video.

7:58But this concept only exists with wireless LAN controllers,

8:02it doesn't exist with a cloud architecture.

8:04So let's talk about that cloud architecture concept.

8:07The cloud architecture started to develop

8:09I would say in the late 2000.

8:11Really caught steam in the early 2010s.

8:13And the idea here was wireless LAN controllers introduce

8:16a lot of complexity.

8:17And we're going to see that here coming up.

8:19And so some of these vendors were showing up and saying,

8:21let's not worry about wireless LAN controllers anymore.

8:23Let's move that to our cloud system.

8:26This means that when an access point comes online

8:29it's going to log in to the cloud system,

8:32and it's going to do everything that the wireless LAN

8:34controller was doing for us.

8:36So there's still a controller at play here.

8:38But it's no longer a physical controller on my network.

8:41Instead it lives somewhere out on the internet,

8:44and the access points know how to find it from the beginning.

8:47So they simply boot up they connect to the controller.

8:51And the controller does all of the same things

8:53that the wireless LAN controller does

8:55with the lightweight architecture.

8:56Now cloud solutions, even though they don't have a wireless LAN

8:59controller, they are still a lightweight architecture,

9:01because once again, if one of these access points

9:04can't access the cloud controller

9:07then it's dead in the water.

9:08It gets its configuration from the cloud.

9:10It gets its management from the cloud.

9:13And so there's very little that these access points

9:15can do apart from accessing the controller environment.

9:19Now again, me as the network admin,

9:21I'm not going to log into the access

9:22points I'm going to log in to this controller

9:24and perform all of my configuration.

9:26And so these access points can once again,

9:28be DHCP, because I shouldn't ever

9:30have to log in to any of them manually.

9:32Now one of the beautiful parts about this architecture

9:34is the licensing element.

9:36Licensing is a big pain point on wireless LAN controllers.

9:40I might get a physical wireless LAN controller.

9:42And this physical wireless LAN controller

9:44can support up to 50 access points.

9:46And as soon as I have 51 access points in my environment, well,

9:51I have a problem, because I can't bring that 51st access

9:53point online.

9:54And this is not only tied to hardware,

9:56it's also tied to licensing, and redundancy gets really tricky

10:00because if that wireless LAN controller goes down,

10:03then I need another one, but do I

10:05need to wireless LAN controllers that both support 50 access

10:07points?

10:08It gets to be a little bit of a hassle.

10:10Well licensing with a cloud environment is very simple.

10:14All I need to do is license my access point

10:16right here to say, OK, I've got one license on this access

10:20point.

10:20And that's all I need to worry about because the controller

10:23environment scales up to as many access points as I need.

10:27Now the other aspect to be aware of as far

10:29as cloud-managed solutions are concerned

10:30is that we do not form network tunnels.

10:34And because we're not forming network tunnels for the data

10:36traffic, we're going to have to address layer two layer three

10:40roaming and some other things that tunneling can help us

10:42with.

10:42So there are definitely advantages

10:44to having the tunnels, but I will

10:45say that lacking the tunnels kind of

10:47comes back to this simplistic architecture.

10:50And for a lot of environments having a simple architecture

10:53matters more than maybe having a few features

10:55that tunneling might have provided.

10:57So autonomous access points, the start of our journey

11:00here going back in time, they had a major scaling issue.

11:04I had to log in each one manually.

11:06I had to make sure all the configuration was there.

11:09I had to manage each one individually

11:10once it was deployed.

11:11And again, once we talk about dozens and hundreds

11:14and thousands and tens of thousands of access points,

11:17this just wasn't something that was going to be able to last.

11:20And so the industry moved towards

11:21lightweight architectures, these lightweight access point

11:24can do nothing apart from a controller.

11:26But that controller can control all of the access points.

11:30And so it can do a lot of things automatically for us,

11:32and we don't have to worry about manually configuring

11:35as many access points anymore.

11:36And so this was a beautiful solution,

11:38but it did rely on a wireless LAN controller, usually

11:41a physical appliance that was installed somewhere

11:43in the network.

11:44Now lastly these cloud-managed solutions, still

11:47a lightweight architecture technically.

11:49But its controller is not on-site anymore.

11:52It's up in the cloud.

11:53And so access points plug in to the network.

11:55I license that access point.

11:57It just goes out it finds its internet-based controller.

12:00I log into a web-based client to configure it as the admin.

12:04And so I get a lot of the benefits

12:05of the lightweight architecture without having

12:07to worry about the hassle of the wireless LAN controller,

12:10and its redundancy concerns, and licensing

12:13and all of these things, just keeping in mind

12:15that we don't get wireless or data tunneling.

12:19And so we're going to talk about tunneling

12:21and the benefits of tunneling.

12:22But again, it is a more simple architecture.

12:24And so for a lot of people, that is

12:26what they care about the most.

12:28And we can figure out how to work around the tunneling

12:31thing by looking at other options there.

12:34I hope this have been informative for you.

12:36And I'd like to thank you for viewing.

0:00[AUDIO LOGO]

0:05Well, as we mentioned in the last video,

0:07wireless LAN controllers can introduce some complexities

0:10into our network.

0:10It's one of the reasons why some vendors have gone exclusively

0:13cloud and they tout the benefits and the simplicity of a cloud

0:17managed environment.

0:18But there are a lot of architectures

0:19out there today that still rely on wireless LAN controllers.

0:22Let's go ahead and understand what exactly a wireless LAN

0:24controller is and what some of these considerations

0:27are that we need to take when we're incorporating them

0:29into our designs.

0:31So as we've mentioned, a lightweight access point

0:33can do nothing apart from a controller.

0:35It's going to have to associate to some kind of controller

0:38in order to function, whether that's

0:40a cloud managed solution, or, once again, a wireless LAN

0:44controller.

0:45So what exactly is a wireless LAN controller all about?

0:48Well, wireless LAN controller can

0:50take on a lot of different forms, actually.

0:52So most commonly, we think of wireless LAN controllers

0:55as being a physical appliance.

0:57This physical appliance is going to get installed into a network

1:00rack, it has network ports, and it's

1:02going to be a little bit expensive because I

1:04have to purchase something that has a lot of hardware in it

1:08and is capable of handling all of these access points.

1:11But the good news is it's a one time spend as opposed to maybe

1:14a monthly subscription.

1:15Now, we can take on other forms as well here.

1:17For example, a lot of vendors now offer a virtual appliance

1:21as well.

1:22The concept of a virtual appliance

1:23is kind of interesting.

1:25It's basically a software version

1:27of the hardware that appears here in the physical appliance.

1:31In fact, it's often the exact same software,

1:33whether I purchase a physical or virtual appliance.

1:36The difference is this is going to cost me less money.

1:38However, it also doesn't come with any hardware.

1:42There's a lot of hardware that I pay

1:44for in the physical appliance.

1:46And so I'm going to have to deploy this

1:47into my virtual environment, so I'll probably

1:50deploy it as virtual machines.

1:52And this is usually going to involve servers.

1:55And so I'm still paying for the hardware.

1:57I'm just paying for the hardware here.

1:59And then I can possibly share that server

2:01with other virtual appliances and such.

2:03So this is very commonly what people do these days.

2:07However, physical appliances definitely

2:09still have value, especially when it comes to tunneling.

2:11Now, this can also actually show up as an embedded concept.

2:16So we might see an embedded controller

2:18on the access points themselves.

2:20This is an interesting one because we just

2:22said lightweight access points require controller.

2:24So what are we talking about here?

2:26Well, what can happen is, if we've got a small site,

2:29I might have, let's just say, three or four access points

2:32here-- we'll say four.

2:33So I've got four access points.

2:35And do I really want to go out and purchase

2:37a physical appliance or a virtual appliance,

2:39some kind of wireless LAN controller,

2:41for this very small site?

2:43Well, maybe what I could do instead

2:45is I can use an embedded controller

2:46on one of the access points.

2:48A lot of vendors support this.

2:49Especially Aruba and Cisco are known for this.

2:51And so I can convert this access point here

2:54into a wireless LAN controller.

2:56In fact, it can play both roles at the same time.

2:58It can have an access point functionality still,

3:01while running the wireless LAN controller, oftentimes, as what

3:05we call a container service.

3:07So this basically just means that it's

3:09leveraging the hardware of the access point

3:11to run different software and usually

3:13built on some kind of Linux operating system.

3:16All that to say, what we're going to do

3:19is allow these other access points

3:20to connect to this access point over here, including itself.

3:25All four of these access points are

3:26going to connect to the wireless LAN controller instance that's

3:29running on that access point.

3:31And then for me, as the admin, I would still

3:33log in to the wireless LAN controller

3:35and configure my access points that way.

3:38That's a pretty cool option for sure,

3:39but it really is intended for smaller environments.

3:42So keep that in mind.

3:43Now, all of these devices are going

3:44to need network access, especially when we

3:46look at the physical and virtual appliances.

3:48And so a lot of these appliances will have 10 or 40 or even

3:52100 gig connections to the network

3:54because as to facilitate all of the access points connecting

3:57to it.

3:58And the larger the scale, the more bandwidth

4:01we're going to need.

4:02Now, if I purchase a physical appliance,

4:04it's going to come with those ports.

4:06If I purchase the virtual appliance,

4:07then I'm going to need to provide

4:09these ports on the server, because we are going

4:11to need a whole lot of network traffic still,

4:14and this is where--

4:15even purchasing a virtual appliance,

4:17we might end up paying for a lot of hardware

4:19that we maybe could have just purchased a physical appliance

4:22at that point for.

4:23But again, if we've got a server where we can share resources,

4:26then it does make sense to do so.

4:27Now, a big challenge with wireless LAN controllers

4:29is the discovery process.

4:31If I have a cloud-managed solution,

4:33the access point knows how to get out to the cloud

4:36because it's been preconfigured with this.

4:38This cloud connection is embedded

4:41in the code of the access point because this cloud system--

4:45it never moves.

4:46It never changes.

4:47It's got the same IP address or the same DNS resolution

4:50no matter who's deploying the access points.

4:53But this, naturally, isn't going to work from a wireless LAN

4:56controller perspective because my wireless LAN controller--

4:59it could be anywhere in my network.

5:01And because it could be anywhere,

5:03it could have any IP address.

5:04And so, we're going to need to come up

5:06with a little more sophisticated method for discovering

5:10the wireless LAN controllers as an access point boots.

5:12So the process is going to look something like this.

5:15The access point is going to boot up,

5:17and it's going to check its local configuration because it

5:20can store local information-- not necessarily channels

5:24or radio power because that's dynamic

5:26and depends on the wireless LAN controller--

5:28but it can store local information

5:30such as, hey, where are my controllers,

5:32especially if I've booted up before?

5:34From there, we've got a lot of different options

5:36for finding our controllers.

5:38One of the most popular is going to be what we

5:40call DHCP and then option 43.

5:43When we do DHCP, this is our dynamic process

5:46for getting an IP address.

5:47And we already mentioned that lightweight access points

5:50can now use DHCP.

5:51And this is another reason why we'd want to do so.

5:53I boot up, I get an IP address from the DHCP server,

5:56but the DHCP server can do more than just hand

5:58out an IP address.

6:00Using one of these options, such as option 43,

6:02we can provide other information.

6:04And so option 43 allows me to provide a list of wireless LAN

6:08controllers.

6:09I can say, here's wireless LAN controller 1,

6:11here's wireless LAN controller 2,

6:13and maybe even here's wireless LAN controller 3.

6:15And so now I've got a primary, secondary,

6:17and tertiary controller that I add to my configuration.

6:20Now, if I'm not using DHCP or my DHCP server

6:23doesn't support option 43, even though it is commonly

6:26supported, we could look at another option.

6:28We could look at DNS resolution as another way

6:31of discovering the WLC.

6:33And so, oftentimes, each vendor will have a very specific name

6:37resolution to look for.

6:38And so maybe we'll try to resolve the vendor name,

6:41and then dash WLC, and then whatever our local domain

6:46is, which, by the way, we are getting the local domain

6:48as part of our DHCP process.

6:50And so I run a resolution against this name.

6:53And at this point, I can get a wireless LAN controller IP

6:56address.

6:57Now, I can only get a single wireless LAN controller IP

6:59here.

7:00And so that access point might connect

7:02to that specific wireless LAN controller.

7:04And then that WLC can pass down redundant to WLC

7:08as part of the process.

7:09So I can still get my list.

7:10I just won't get it as part of the DNS process.

7:13Now, another option that doesn't always

7:15work very well, because it requires a smaller network,

7:18is that the access points can also perform a broadcast.

7:22A broadcast message is only going

7:23to go within a VLAN or a layer 2 domain.

7:27And so, this broadcast is going to work just fine if the access

7:30point is connecting to a switch here,

7:32and the wireless LAN controller is also connected to a switch,

7:35and they're on the same VLAN.

7:36It's all part of the same layer 2 domain.

7:38That's going to work just fine to send out a broadcast.

7:41However, as soon as my network gets a little more

7:44complex, and now it actually goes through a router, a layer

7:473 domain here, to get to the wireless LAN

7:50controllers over here, let's say, and my wireless LAN

7:53controller is no longer associated or connected

7:55with that original VLAN, well, now, a broadcast

7:57isn't going to work.

7:58Because broadcasts only go as far as the layer 2 domain,

8:01and then they are cut off.

8:02And so, at that point, I'm going to have to use DHCP or possibly

8:05DNS in order to find the wireless LAN controller over

8:08here.

8:08Now, lastly, a lot of vendors do still allow me, as the admin,

8:12to do a manual configuration.

8:14And so, remember my example where

8:15I had all my access points on my desk,

8:17and I was moving my console cable around and configuring

8:21them.

8:21This still is an option.

8:23It's certainly not ideal.

8:24But it is something we could do.

8:26We could get in there.

8:26We could configure my list of access points--

8:28or wireless LAN controllers, rather.

8:30I could do wireless LAN controller 1, WLC 2, WLC 3,

8:33and I can do that manual configuration

8:35on every access point.

8:37And it's just not going to scale.

8:39We give up scalability here, once again,

8:41because we're basically reverting

8:42to autonomous configuration.

8:44At least, it's only for the sake of finding a controller,

8:46but it is still manual.

8:48Now, once the access point does find the wireless LAN

8:50controller, it will connect to it.

8:52And it will form that tunnel, which

8:53we're going to talk about more in the next video

8:55Now, there are definitely some design implications

8:58that we need to consider because, well, vendors do still

9:01have wireless LAN controllers that are

9:03going to go into the network.

9:04And so that's going to impact our design

9:06in a number of different ways if that's the solution we're

9:09choosing to use.

9:10So we already talked about it.

9:11But we do need to consider licensing and generally sizing

9:15of the wireless LAN controllers because a wireless LAN

9:18controller typically will support

9:20some number of access points.

9:21Now, it varies by vendor.

9:23We might have a wireless LAN controller

9:25that just straight-up supports 100 access points.

9:27Or we might have one that can support 100, 150, or 200,

9:30depending on the licensing.

9:32And so, from a hardware perspective,

9:34it's limited to 200, but I might purchase it

9:36and, by default, it supports 100.

9:38And I would have to pay for more licensing if I want 150 or 200.

9:42But we still have to be careful.

9:43Again, any time we're talking about hardware,

9:45we'll have hardware limitations.

9:47And so, if I have to install a 201st access point,

9:50that's going to be a bad day.

9:52And so we need to take this into account.

9:54And we need to have growth factored into our design.

9:57Because if I have, let's say 185 access points today,

10:02this wireless LAN controller model will support that,

10:05but that's less than 10% growth at this point to get up to 200.

10:10And so, the reality is, if I add a small site

10:13or I just need to bolster up my wireless solution a little bit,

10:17then there's going to be growth involved.

10:18And I'm really risking a lot here because the wireless LAN

10:21controller is very expensive to rip and replace.

10:24We want that to last five or six years before

10:27we have to invest in hardware once again.

10:29We also need to consider failover.

10:31And so, I'll just write this out as redundancy.

10:34Redundancy is a big concern.

10:36Because if I have a single wireless LAN controller,

10:39and I've got a bunch of access points out here

10:41that are all connecting into that wireless LAN controller,

10:44what happens if the wireless LAN controller fails?

10:46At this point, I would hopefully have another WLC

10:49that those access points can resolve to.

10:52Again, we're typically providing a list, like we said,

10:54of several wireless LAN controllers

10:56for the purpose of redundancy.

10:57These access points need to stay associated with a controller.

11:01Otherwise, they will go down, and they'll

11:03take the Wi-Fi network down with them.

11:05And this is well and good other than wireless LAN controller

11:08redundancy starts to get a little bit complicated.

11:10Because is this per site, or is it for the entire organization?

11:15And furthermore, how do I license these?

11:17Let's say I have 35 access points.

11:19I decide that a 50-access point controller is good enough.

11:22Well, do I license both of these for 50 access points?

11:26Because now I'm paying for a lot of licensing

11:28that I'm never going to need.

11:29But at the same time, I need to support all 35

11:32on one of those wireless LAN controllers

11:34in the event of a failure.

11:35Otherwise, I could load balance between them.

11:37Now, some vendors support the concept of hot standby

11:40which means that they share licensing,

11:42and so that issue can be resolved.

11:44But we do need to make sure that we are

11:46deploying a redundant solution.

11:48And furthermore, we need to consider where, on the network,

11:50the wireless LAN controllers will go.

11:52And we'll be talking about that as part

11:53of our tunneling conversation.

11:54So wireless LAN controllers, they

11:56are at the heart of a lightweight architecture.

11:59In a lot of cases, we're still deploying wireless LAN

12:01controllers as part of some of these solutions.

12:03So if it's not based in the cloud,

12:05it's going to be based in my network somewhere.

12:07And as we saw, that can take a lot of different forms,

12:10whether it's a physical appliance, virtual appliance,

12:12et cetera.

12:12Now, our lightweight access points,

12:14they have to discover the wireless LAN controller.

12:17Again, in a cloud solution, it's simple to do

12:19that because I just resolve my DNS or whatever.

12:22The access points are pre-configured with that,

12:25and they can go out and find the cloud.

12:26Whereas, with my network, they have no idea where

12:28the wireless LAN controller is.

12:30And so maybe we'll do DHCP option 43.

12:32It's a very popular option.

12:34We might do DNS.

12:35We might do broadcast.

12:36And so we've got a lot of different ways

12:38of doing that up to and including, potentially,

12:41manually configuring those access points, which

12:43is not ideal, but we can do it.

12:45Now, lastly, we've got to make a lot of design considerations

12:48here with wireless LAN controllers.

12:49We have to think about the form factor like we talked about.

12:52We also have to think about the licensing.

12:54We have to think about the redundancy.

12:55And so, there's a lot of different considerations

12:57we have to make as far as these wireless LAN controllers are

13:00concerned.

13:01We also have to consider where in the network

13:03we're deploying these.

13:04And so we'll find that the location of the wireless LAN

13:06controller matters a lot when we are tunneling our wireless

13:09clients.

13:10I hope that it has been informative for you,

13:12and I'd like to thank you for viewing.

0:00[AUDIO LOGO]

0:05We've mentioned several times that when a lightweight access

0:07point connects to a wireless LAN controller,

0:09it's going to form a tunnel, and that tunnel

0:12is known as a CAPWAP tunnel.

0:13In this video, we're going to explore

0:15the implications of these CAPWAP tunnels

0:17and why they matter so much, because if we're

0:19throwing our wireless clients into these CAPWAP tunnels,

0:22it is going to fundamentally change the way

0:24our network architecture comes together.

0:26And let's see this in action.

0:27We've mentioned that lightweight access points are

0:29going to need a tunneled connection to the wireless LAN

0:32controller.

0:33And this tunnel is going to be known as a CAPWAP tunnel.

0:37CAPWAP stands for the Control And Provisioning

0:39of Wireless Access Points.

0:40We're going to send three different types of traffic

0:42across this link.

0:44We're going to send control traffic,

0:46meaning that this is the access point basically communicating

0:50with the wireless LAN controller and staying online.

0:52We're going to have management traffic, which

0:54is controlling the radio frequencies

0:57and controlling the radio power and such.

0:59But then we're also going to send our data traffic.

1:03This data traffic being transmitted through the tunnel

1:05is what makes things interesting.

1:07And in order to understand why, let's

1:09talk about what a tunnel is.

1:11In networking you may recall studying the OSI model.

1:14The OSI model lists out a bunch of layers.

1:16We start at the physical layer, and data

1:18link layer, network layer, and so on and so forth.

1:20And the idea is that we are going to use

1:23the concept of encapsulation.

1:25Encapsulation says that I'm going

1:27to take a packet of information--

1:29so I've got some amount of data, and then I'm

1:31going to take that data and put it inside of a header.

1:34And so I'm going to place this header right in front

1:36of the data, and it basically describes

1:38what to do with this data.

1:40But what's fascinating about this

1:41is I can take all of this information,

1:43including the header, call it data,

1:46and then I can put another header in front of it.

1:48So now, I have what was originally a header

1:51and a bunch of data in here, and now it

1:54has a new header in front of it.

1:55And this is exactly what we do as we move data

1:58from one layer to the next to the next within the OSI model.

2:02For example, I might have an IP header here,

2:04so this is a layer 3 header, and it's

2:07got the IP address in there, and everything's good there.

2:09But then I encapsulate that and put it

2:11inside of an Ethernet header.

2:13And the Ethernet header is going to have the MAC addresses

2:15and all of that.

2:16And so while this is a natural part of our networking process,

2:19where we have TCP headers and IP headers and Ethernet headers

2:23and all of these things, we can actually

2:26take advantage of encapsulation and put it into a process

2:29that we call tunneling.

2:31Tunneling is typically when we encapsulate

2:34within the exact same header.

2:35So for example, I might have that IP header

2:38that I just mentioned.

2:39It's got an IP address and everything in there.

2:41And then it's got a bunch of data.

2:43And normally, I would encapsulate this in Ethernet

2:46and send it across the network.

2:47But I can take this as data, and I can put another IP header

2:52in front of it.

2:53And this IP header is going to direct

2:56this amount of information out towards another location.

3:00It allows me to essentially rebound traffic.

3:02So if a source starts out here, and the destination

3:07is over here, I can have two IP addresses.

3:10I can have the outer IP header that says, hey,

3:12I want you to go up here to this device, whatever

3:15that device is.

3:16This device de-encapsulates it, looks at the inner IP header

3:20and says, oh, you really want to go down here

3:22to this destination.

3:23Now, why I would want to do this,

3:25there's a lot of reasons for it.

3:27For example, this could be a firewall,

3:29and I want to inspect that traffic before it

3:30goes to the destination.

3:32Or hey, guess what, in the wireless world,

3:34this could be a wireless LAN controller.

3:36And I know that this wireless client down here

3:39is trying to communicate with some destination

3:41out on my network, whatever that is.

3:43But that traffic needs to go through the wireless LAN

3:46controller first.

3:47And so this is why we call it tunneling, because all

3:49of the devices that are in the path

3:51here, the switches in these routers,

3:53they have no idea that you're trying

3:55to get to this destination.

3:56I just know that you're trying to get to the wireless LAN

3:59controller up here, and so I'm going to forward you

4:01towards that destination.

4:03Now, this is why the location of the wireless LAN controller

4:06starts to matter a whole lot, because if I'm

4:09tunneling my wireless client to a different location, well,

4:12my wireless clients might as well be

4:14attached to this wireless LAN controller physically.

4:17Yeah, it's not physically attached there.

4:19It's physically attached to the access points down here.

4:22However, this is what we call our logical point of presence.

4:27The client is going to show up on the wireless LAN controller

4:29and then get forwarded down towards the destination.

4:32So as far as the network is concerned,

4:35it only sees the client show up at the wireless LAN controller.

4:39Now, this has some implications.

4:40For example, let's say that I have an access point here,

4:43and it's connected to a switch, and that switch

4:46goes through a firewall.

4:48And that firewall is going to connect me then to,

4:52let's say, the data center.

4:53Let's say we're firewalling all of the traffic,

4:55making sure that all of our applications and data,

4:58they're all safe in the data center.

4:59We want to inspect everything here.

5:02Life is good.

5:02We're forwarding traffic in and out of there.

5:04And then I've got my wireless LAN controller

5:06inside the data center.

5:08Well, here's the problem.

5:09If I've got a client that attaches

5:11to this wireless access point, and then the access point

5:14sends it through the CAPWAP tunnel

5:16to the wireless LAN controller, look at what we just did.

5:19We just bypassed the inspection of that firewall,

5:22because we embedded it inside of the CAPWAP tunnel.

5:25The firewall does see that traffic.

5:27However, it sees it as the source being the access point

5:31and the destination being the wireless LAN controller.

5:34By default, it's not going to look inside of that IP packet

5:37and see that there's more header information within.

5:40And so now what we have is a wireless LAN controller

5:43that's connected in through a switching infrastructure.

5:45And maybe we've got our servers down here.

5:48And so what ends up happening is the servers

5:50are attached to the switching infrastructure,

5:52and I'm placing my clients directly into that switching

5:55architecture.

5:56And once again, those clients have fully

5:58bypassed the firewall in the middle.

6:00So we have to be very careful about where

6:02we place the location.

6:03And the question is, where does the wireless LAN controller

6:06belong in the network?

6:08Well, in a lot of cases, we would

6:10recommend that it goes into the distribution layer.

6:13The distribution layer is part of our network architecture.

6:16We're going to find that we've got a network core here.

6:18We've got maybe the data center hanging off over here.

6:22We maybe have our wide area networking hanging off it

6:24as well.

6:25And then on a per-building basis,

6:27we usually have a distribution layer that

6:29connects to the access layer.

6:30And we already mentioned that the access layer

6:32is where all of our access points connect.

6:35And so we know that part.

6:37But now we're suggesting that the wireless LAN

6:39controller be connected here at the distribution layer.

6:42The distribution layer and the access layer,

6:44these typically form a single layer 2 domain.

6:47And so that keeps our clients within the same layer

6:492 domain in the same IP addressing space.

6:51It also makes sure that our clients don't magically

6:54show up over here in the data center,

6:55and they pop into existence.

6:57It's like we teleported them almost,

6:59and in doing so potentially bypassed security measures.

7:02The reason why I keep bringing up the data center

7:04is because I've seen a lot of wireless LAN controllers

7:06get deployed into the data center, which makes sense.

7:09This is a highly resilient, highly redundant environment.

7:12We have server racks.

7:14And that's exactly where we need to deploy our wireless LAN

7:16controllers.

7:17And if we're going to deploy wireless LAN controllers

7:19for the entire network, well, at this point,

7:23it makes sense to deploy something

7:24that we might consider global into our data center.

7:27However, despite all of these advantages,

7:29it really is better to deploy our wireless LAN controllers

7:32into the distribution layers for their associated buildings.

7:35Now, herein lies the challenge of the distribution layer

7:38though.

7:38And a lot of organizations have many distribution layers.

7:42And so I've got another building over here

7:44that has its own set of distribution switches

7:47and access layer switches.

7:48And so maybe this is my headquarters building here,

7:51but maybe this is my remote site, or a branch office,

7:55and then I might have a lot of these branch offices.

7:58So do I need wireless LAN controllers here as well?

8:01Well, with this architecture, we would.

8:03And so we would spec out our wireless LAN controllers

8:05to go at every site.

8:06But then we'd have to consider a redundancy,

8:08and so I need maybe a second wireless LAN controller

8:11at each location.

8:12Or potentially, I could rely on the other site

8:14for my failover in case a wireless LAN controller

8:17goes down.

8:18And so there's a lot of conversations to be had here.

8:20But as far as a clean network drawing or clean network

8:24architecture with wireless LAN controllers,

8:26this is typically what we're going to aim for.

8:28And then we can adjust accordingly based

8:30on the needs of the network.

8:31Now, if we were to decide, hey, we've got so many locations.

8:34We really need this global concept.

8:35We've got a couple of options.

8:37We could deploy it into the network core,

8:39although we don't like to deploy anything to the network

8:43core other than just the core switches,

8:45and so that's not very ideal.

8:46And the other option is we do deploy it into the data center.

8:49However, we would want to deploy it

8:51into a part of the data center that is still

8:53firewalled and isolated from the rest of the data center

8:57networks.

8:58Now, there are a couple of benefits

9:00to deploying this tunneling mechanism,

9:01because we could say, you know what, the tunneling is no good.

9:04I want to shut it down.

9:05A lot of vendors will actually say, hey,

9:08you don't like this idea?

9:09Let's just go ahead and get rid of the data traffic.

9:12We'll drop that off locally like any other solution would.

9:15And we'll only send control and management traffic

9:17across the line.

9:18And so that's certainly an option,

9:20something that we could do if the CAPWAP tunneling gets

9:22too complex for us.

9:24However, again, there are reasons why

9:25we'd want to leave it in place.

9:27One of the biggest ones is the elimination of layer 3 roaming.

9:31Layer 3 roaming is a highly disruptive form

9:33of roaming that occurs when I have an access point here

9:36advertising an SSID, an access point over

9:39here advertising an SSID.

9:41And I want to roam from one access point to the other,

9:44but there's a layer 3 boundary in the path.

9:47And so if this is the case and I'm actually

9:49roaming between layer 3 domains, I have to change my IP address.

9:53And if I have to change my IP address,

9:55again, that is a super disruptive operation.

9:58And for example, any phone call you're

9:59part of is going to drop.

10:01Well, by tunneling, again, we kind of ignore

10:03the underlying infrastructure.

10:05We are bypassing even layer 3 devices

10:07like we bypassed our firewalls.

10:10And so it actually eliminates the concern

10:12with layer 3 roaming.

10:13And so we can still have these layer 3 devices,

10:15whether that's layer 3 switches, or routers, WAN circuits,

10:18et cetera.

10:19We can have that in between our access points,

10:21and we don't need to worry about changing IP addresses.

10:24So that's a huge benefit.

10:25That would be number one.

10:26The second benefit is a callback to the concept of our guests

10:30being forwarded into the DMZ.

10:32I mentioned earlier that this tunneling concept

10:34can be used for this.

10:35And that's a great way to do it, because if I place now

10:38my WLC into the DMZ near the internet, at that point,

10:42my guests get forwarded directly into the DMZ simply

10:45via the CAPWAP tunneling.

10:47And so it's an automatic way of doing things,

10:50whereas without CAPWAP tunneling,

10:52this architecture would be very complex to deploy and manage.

10:56So this concept of CAPWAP tunneling,

10:57it's going to send all of our management, our control,

11:00and our data frames by default to the wireless LAN controller.

11:03And this has some heavy implications.

11:05For example, where in the network

11:07do we want to deploy the wireless LAN controller?

11:09If we deploy it into, for example, the data center,

11:12we might bypass firewall inspections,

11:14because tunneling truly hides the data

11:17traffic until it shows up after it has been de-encapsulated.

11:20And so it teleports our clients wherever the wireless LAN

11:23controller lives.

11:24And so we'd probably want to consider

11:26deploying our wireless LAN controllers

11:28into the distribution layer if we can.

11:29However, it's going to be a case-by-case basis.

11:32Now, tunneling does have its benefits.

11:34So even though we could opt to maybe get rid of the tunneling

11:36altogether, even in vendors that typically support

11:39wireless LAN controllers and CAPWAP tunneling.

11:42We would not necessarily just want to do that,

11:44because it does help with layer 3 roaming.

11:46If that's a concern in our environment,

11:47and you can roam between layer 3 domains,

11:49then we'd probably want to keep this tunneling in place.

11:51It also helps us with the concept of anchoring our guests

11:55into the DMZ.

11:56And so there are definitely benefits

11:58to deploying our CAPWAP tunnels.

12:00We just need to decide if it makes sense

12:02or if it's better to go with a nontunneled solution

12:04and maybe even go with a cloud controller at that point

12:07so that we just don't even have to worry about the wireless LAN

12:10controller.

12:11I hope this has been informative for you,

12:12and I'd like to thank you for viewing.

0:00[AUDIO LOGO]

0:05Sometimes, in the wireless world,

0:07we're not even worried about our wireless clients anymore.

0:09We are simply going to use wireless

0:11to connect our network to another network, usually one

0:14that we also own.

0:16For example, if I've got my headquarters in this location

0:19and I just purchased an office building maybe down the street,

0:23I could potentially, rather than tying

0:25into expensive fiber, monthly charges and all of that,

0:28I could potentially put a wireless bridge up

0:30on both sides and communicate wirelessly with one another.

0:33It's a great way to deploy cost-effective wide area

0:35networking and connect my disparate networks together.

0:38So in this video, we're going to take a look at what exactly

0:40it looks like when we perform wireless bridging,

0:42as well as what some of the considerations we need to make

0:45are as part of our wireless designs.

0:47We often think of Wi-Fi as being used to connect clients

0:49to the network.

0:50But wireless can be used as a form of wide area networking,

0:54or what we would call the WAN.

0:55Wide area networking is designed to basically connect

0:58our local area networks together.

1:00So I might have a LAN at one building, a local area

1:02network at another building.

1:03And I'm going to go through this wide area network

1:06in order to connect the two.

1:07And there are a lot of different options out there.

1:09I could get some fiber connectivity.

1:12I could certainly go through a service provider,

1:15maybe get an MPLS circuit, but there's

1:16a lot of different circuit types out there.

1:18However, wireless bridging is a very interesting proposition.

1:23The reason for this is usually these options

1:26are very expensive up front, and they require

1:29some amount of spend per month.

1:32If we have to spend per month, this

1:33is going to add up over the long run as well.

1:35Whereas wireless, this is a one-time spend.

1:38I purchase hardware that I can mount on both locations,

1:42and then that hardware communicates

1:44with the other hardware, and I don't

1:46have to pay anybody anything a month because I've set this up

1:49and I'm running it myself.

1:51Furthermore, bridging can be point to point-- meaning

1:53I have two bridges pointing right at each other--

1:56or it can be point to multi-point.

1:58Point to multipoint means I might have an HQ here,

2:01and maybe I have some sort of campus.

2:03And so I've got a lot of buildings

2:04out here that I want to connect to.

2:06Well, I could deploy one wireless bridge here--

2:08draw this as a tower, sort of a beacon I suppose--

2:11I've got one bridge up here, and I'm

2:13communicating with all of these other bridges at a time.

2:17And so that further reduces the complexity of my network

2:20and reduces the amount of hardware that I have to spend.

2:23Now, the way this is typically going to work

2:25is I'm going to have my building here and a building over here,

2:28and I have to try to get my wireless signal across from one

2:31building to another.

2:32This is going to involve what we call line of sight networking.

2:35I'm going to have to be able to see the other side.

2:37So if there's a giant tree in the way here, well,

2:40that's not going to work in the same way that

2:41if there's a bunch of buildings in the way--

2:43maybe this is a metropolitan area--

2:45I'm not going to be able to make that work either.

2:48And so I'm going to want to mount

2:49my bridges as high as possible.

2:51So maybe I mount it to the side of the top floor of my building

2:54if the buildings are tall enough.

2:56However, if they're not tall enough,

2:57I might actually install a wireless tower outside.

3:01And so, by the way, these could be miles apart.

3:03I know I've got them drawn sort of right next to each other,

3:06but maybe I've got my two wireless towers now built,

3:08and I mount a bridge on the top of each one of these.

3:11So, yeah, building a tower is certainly

3:13going to increase the cost of the solution.

3:15But again, I'm not paying anybody per month,

3:17and so it makes a whole lot of sense to do this.

3:19And furthermore, burying fiber between these locations

3:22would certainly not be free either.

3:24And so, at this point, I'm communicating to one

3:26another wirelessly this way, and I run a network connection

3:29down off of each wireless bridge and connect it

3:32into my switching infrastructure.

3:34Now, line of sight is good, but we absolutely

3:36have to understand the concept of what

3:38we call the Fresnel Zone.

3:40The Fresnel Zone is a three-dimensional space

3:43that exists outside of line of sight.

3:46And so, let's say we have two wireless towers once again.

3:50And so, we've got wireless bridges

3:51at the top of each one of these.

3:53And so, I am now going to be pointing

3:55my antennas or my bridges at one another and in most cases,

3:59I would assume that if I can see each other

4:01and I've got line of sight all the way across,

4:03then I'm good to go.

4:04Even if there's a tree right here, as long

4:06as I can get across to the other side, I can see the other side,

4:10then I should be good.

4:11But this is not how physics works, at least as

4:14far as our RF signals are concerned.

4:16Instead, the wireless signals are actually

4:18going to form this three-dimensional oval shape.

4:22And so, this oval shape is, once again, three-dimensional,

4:25and it needs to stay clear.

4:27This means that a tree that grows into this Fresnel Zone

4:30space, even though it's below line of sight,

4:33it's still going to cause me wireless problems.

4:35And so I have to be really careful about this

4:37for a couple of reasons.

4:38First of all, I might expect that line of sight

4:40is the only thing I need to worry about.

4:42But the other concern is there might

4:43be some very low trees down here and we run our calculations

4:47and we say, OK, everything's good because the Fresnel

4:50Zone is empty or clear.

4:52However, trees grow over time.

4:54And so, a couple of years later, we

4:56might find that this tree is no longer that short

4:58and it's actually starting to poke into the Fresnel Zone

5:01here.

5:01Now, there's still a lot of grace

5:03to be shown in the Fresnel Zone.

5:04I mean, we want the Fresnel Zone, ideally,

5:06to be 100% clear.

5:08Certainly, that is the ideal.

5:10However, from a wireless performance perspective,

5:12if we can have 60% be clear, then we

5:15would call this acceptable.

5:17It's acceptable because we are still

5:19able to get our wireless signal through with enough performance

5:23for the wireless network to give us what we need.

5:26Now, one other problem in all of this

5:28that we might need to consider is the Fresnel Zone's impact

5:31with the Earth bulge.

5:33The Earth is round.

5:35And this is one of the ways that we know the Earth is round,

5:38because if I build a tower here and I build a tower that's

5:42really far away, typically across great distances,

5:45then I'm going to have problems even if I'm looking at-- again,

5:49I see line of sight here, but even if I draw the Fresnel

5:52Zone, this might become a problem

5:54because the Earth being round can actually

5:56poke into that Fresnel Zone.

5:58Now, we just said that 60% clear is acceptable.

6:01However, naturally, the Earth bulge

6:03is going to matter more on longer distance links.

6:06For example, if I've got a really long distance link

6:09and this is many, many miles, well, now I

6:12might have a tower here that, yeah, we've got line of sight

6:14with each other like this.

6:16But as soon as I start to draw the Fresnel Zone,

6:19we see that there's a big problem with this.

6:21And we've got more than 40% potentially

6:24being blocked by the Fresnel Zone,

6:26especially if now we talk about there

6:28being some trees in the path.

6:30Maybe there's a forest in between here.

6:32And so the Earth bulge is only going

6:33to be something we need to worry about

6:35if we're over roughly 7 miles, which is 11 kilometers.

6:39And so, if you've ever heard the company 7-Eleven,

6:42that's a way to think about this, I suppose--

6:447 miles or 11 kilometers.

6:46If we're over that, then we are going

6:48to need to factor in the earth bulge

6:50into our Fresnel Zone calculations

6:53and make sure that we are building our towers

6:55higher than we would have built them otherwise.

6:57So this concept of wireless bridging-- it's

6:59an application that's going to allow

7:01us to extend our networks from one site to another

7:03without having to go through a service provider

7:06or bury fiber or anything like that.

7:08We can simply mount wireless bridges to the buildings,

7:11or possibly towers, and connect to each other that way.

7:14Now, even though line of sight sounds good on paper,

7:17we need more than just line of sight.

7:19And the physics really starts to get involved here,

7:21and we need to keep the Fresnel Zone clear.

7:23The Fresnel Zone is this three-dimensional space around

7:26the line of sight line that--

7:27if we can keep it at least 60% clear, we should be good to go.

7:30Naturally, we want to keep it as clear as possible,

7:33and the more we keep it clear, the fewer re-transmits and such

7:37we're going to have.

7:39Now lastly, we've got to consider the Earth

7:40bulge when it comes to long distance links.

7:42The curvature of the Earth starts to impede potentially

7:45on that Fresnel Zone.

7:46And so we've got to keep it clear once again.

7:48And if a link is over 7 miles or 11 kilometers,

7:51this is where we would need to factor the Earth

7:54bulge into our account and make sure

7:55that our towers are taller, or maybe our bridges are mounted

7:59taller, at least regardless of how we do that,

8:02in order to account for the bulge.

8:03I hope that it has been informative for you,

8:05and I'd like to thank you for viewing.

0:00[AUDIO LOGO]

0:05All right, the skill is done.

0:06So it's time for that review to make

0:08sure we've got it all down.

0:09First up out of four questions, how does licensing

0:12work with a cloud-managed wireless solution?

0:19So when it's cloud managed, we don't

0:20need to worry so much about licenses on a controller

0:24basis, that kind of thing.

0:25However, we are going to need a license

0:27but where that's going to be mapped

0:29to each individual access point.

0:31So if we want an access point to be part of the solution,

0:33then we would license that access point.

0:35In a cloud-managed solution, we don't actually

0:37have wireless LAN controllers.

0:39Saying each cloud requires one license is

0:41going the wrong direction here.

0:42We usually only have one cloud solution.

0:44And it's certainly not licensed for-- at least,

0:46in my experience-- maybe some vendor out

0:48there has a license for each solution.

0:50But usually, you are paying a per-month or per-year license

0:54per access point that's part of the solution.

0:57Next question, which of these discovery methods

0:59requires a wireless LAN controller

1:00to be on the same VLAN as the access points?

1:08Well, the only one that's going to require

1:10that we all be on the same VLAN would be the broadcast option,

1:13because a broadcast is contained within a VLAN.

1:16That's the nature of a broadcast message in networking.

1:18All of these other options are going

1:20to be able to allow access points to connect

1:22to the wireless LAN controller wherever it is.

1:25And as I've mentioned during the skill,

1:27DHCP Option 43 is typically our most popular option

1:30because it gives us that list of controllers to start with.

1:34And it happens as part of the DHCP process

1:36rather than having to do anything other than simply

1:38getting a DHCP message back.

1:40Question three, what is a concern

1:42with deploying wireless LAN controllers

1:44into a sensitive part of the network such as the data

1:46center?

1:52Our big concern here is that our wireless clients

1:54are getting tunneled via CAPWAP into wherever the wireless LAN

1:58controller lives.

1:59And so if we're going into the data center,

2:01well, that data center might have a firewall in the path.

2:04But because the wireless LAN controller lives here

2:06and we have our wireless clients out here that are communicating

2:09with it, they will get tunneled into the data

2:12center via CAPWAP.

2:13So let's make sure we're very intentional about where

2:15we're placing our wireless LAN controllers.

2:17They could physically go into the data center,

2:19so long as they logically are segmented from data center

2:22traffic.

2:23All right, last question, wireless

2:24bridging falls into which networking category?

2:32So we've got local area network, wide area network,

2:34metropolitan area network, and personal area network.

2:38The answer here is going to be B, wide area networking,

2:41because wide area networking is all about connecting

2:43our local area networks together,

2:45like we had mentioned.

2:46So I might have a bunch of local area networks out here,

2:48a bunch of buildings that all have their own switches

2:51within them, connecting to access points.

2:53And we need to connect all three of these together.

2:56And so we could do this via wireless.

2:58And that's exactly what the wide area network

3:00is supposed to do for us is to connect

3:02these disparate local area networks together.

3:04And with that, this quiz is done.

3:06If you didn't quite connect the dots on some of these concepts,

3:08then be sure to go back and review the materials

3:10in order to get it all down.

3:11Otherwise, congratulations on completing

3:13Define Wireless Network Architectures.

3:15I hope this has been informative for you,

3:16and I'd like to thank you for viewing.