Define Wireless Network Architectures

0:00[AUDIO LOGO] Welcome to define wireless network architectures. As we move into domain 2 of the CWDP blueprint, it is time for us to get more technical. And so in this video series, we're going to be talking about wireless network architectures, such as the original autonomous access points that we used to deploy a long time ago, and certainly we could still find low-end solutions today that leverage that architecture. But for the most part, we are going to be focusing in on cloud and lightweight architectures that involve wireless LAN controllers.

0:35Whether it's cloud or wireless LAN controller base, it's going to be what we call a lightweight architecture. Our access points are not going to be very useful, unless they connect to some kind of centrally managed system. Ultimately, what we're talking about here is we more so with wireless than with other technologies, we have so many devices to manage. With wireless or maybe I should say with local area network type of deals, we're talking about access layer switches, core switches, distribution switches, we can wrap our arms around that. There's not nearly as many switches in our infrastructure as we have wireless access points, because we could have dozens, if not hundreds, at every single one of our locations.

1:14And some enterprise organizations might find that they have thousands or tens of thousands of access points. But managing each one individually is not going to scale particularly well. And so this is why we introduce the lightweight architecture to say OK, now our access points are all managed centrally by some kind of controller system, whether again, that's cloud or a wireless LAN controller that's doing it. And so once we understand that architecture, we can then start to look at some of the ramifications of that architecture. Especially when we have wireless LAN controllers, we have this concept of CAPWAP tunneling.

1:48The concept of a network tunnel basically says if I am physically in this part of the network, that's great, except I'm going to tunnel that traffic to a different part of the network. And then as far as the rest of the network is concerned, that's actually where I am. So we'd call that my logical point of presence versus my physical point of presence. And so we're going to learn this concept of tunneling, and understand how it can benefit us in a wireless LAN controller architecture. We're going to also talk a little bit about the concept of wireless bridging. Wireless bridging is the idea that I can extend my network between two sites using a wireless connection.

2:22And so this is wonderful. If I've got a site that is down the street or within line of sight, then I don't need to bury fiber. I don't need to do anything expensive. I can simply buy a couple of wireless radios, and point them at each other. And I can connect my network that way. But there are definitely some things we're going to want to take into account when we're planning to install wireless bridge links. So we're going to again get a little bit more technical as we start to unpack the different types of wireless architectures that exist and the ones that we might end up recommending as part of our designs.

2:54So with that, let's dive in. I'll see you in the next video.

0:00[AUDIO LOGO] Let's kick off our conversation by talking about where we came from, which is the idea of autonomous access points. Autonomous access points where we talked about where every access point needs to be configured individually. And so that doesn't scale particularly well. And so we came up with this lightweight architecture. And one of the ways we can manage the lightweight architecture is with a cloud-managed solution. So let's go and take a look at these two concepts before we dive into what life looks like with wireless LAN controllers coming up.

0:32When you look at the start of our wireless architectures, we all began with the concept of autonomous access points. And eventually, the wireless world evolved its practice and deployed something that we call a lightweight architecture. Now this lightweight architecture originally started with wireless LAN controllers. And wireless LAN controllers really are a very different type of animal. We still have them in a lot of architectures today. And so we're going to talk about that in the next video. But what we've seen as well coming from the lightweight architecture, is the ability to run a lightweight architecture using a cloud management solution.

1:07And so we've got a lot of vendors that support cloud management. And there are advantages and disadvantages to that. And so in this video, we want to focus a little bit on the autonomous world as well as the cloud-managed world because it doesn't change our underlying network architecture, whether we're running autonomous or cloud-managed, it only changes the way we manage things. Whereas a lightweight architecture running a wireless LAN controller, that truly does change the way our networks work. So how exactly did the autonomous solution work? It has been a while since we've really relied on this.

1:38Wireless was developed in the late '90s, believe it or not, it's been around that long. And we used autonomous all the way through, I would say, the mid-2000s. It was around the mid-2000s that the lightweight architecture first showed up. And so during this time, our access points were treated pretty much like any other network device. Any network device that sits on our network even today, for the most part, we're logging in and we are doing a manual configuration. This configuration is typically done via CLI or possibly some kind of graphical user interface, usually through our web browser.

2:11And so we were configuring each individual access point. We also had to upgrade and manage the software for every single access point. And one of the reasons why I absolutely love wireless is because this is where I got my start in the industry. I was originally hired to basically mount access points and learn how to configure them. And so during this time frame, I remember pulling out dozens of boxes for a wireless install. And I'd pull all the access points out, and I'd stack them all up on my desk. And I really had a good process down for this, a good process for mid-2000s, I suppose.

2:44And I had all of my access points lined up and stacked. And I would move my console port through each one of the access points. I had I think three or four power cables, so I would power four of them up at a time. I'd configure one, move the power cord from the first access point to the fifth, so it could start powering up. And then I'd move my console cord to the next one, and start configuring it. And so the reality is that if I had a wireless deployment with 200 access points, which wasn't at all uncommon, I would spend about three days just configuring all 200 of those access points.

3:18Because each one needed to be manually configured. And it took a little bit. I mean half of the wait time was just the process of powering on access points and moving the console cable across. And so this was, as you can imagine, not an ideal situation. It's one thing to say, OK, I'm going to install a bunch of switches, but even a bunch of switches, I mean, maybe 20 switches in a large deployment. And a lot of cases, maybe two or three switches for every dozen or two dozen access points.

3:49And so access points had a scaling problem where the rest of the network did not. And it's not just a matter of configuring and upgrading but also the fact that we had to manage the access points. We think about all of the things that our wireless systems do for us these days. For example, we'd have to tune the radios manually. If one of the radios was turned up too much, I'd have to log into that access point, and I'd have to turn that radio down. I'd have to select channels, so the channel assignment was a manual process. I needed to make sure that if I was going to deploy 200 access points, that I had all of the channels figured out and properly labeled on the access point, so they could be installed into the correct places based on that channel scheme.

4:29Now in fairness, some vendors did have a management solution that would do this for us, but this was not what we'd consider to be one of our modern management systems. They would basically log into these access points, it would perform CLI commands. And sometimes this would work well, and sometimes it wouldn't. And so we never really knew what we were getting by deploying one of these vendor-based management solutions. And just to make things more complex, by the way, because of all of the manual logging in and performing CLI commands, whether that was a management solution or whether that was us, we really had to rely on static IP addresses, because if I was going to log into a specific access point and change a specific radio or a specific channel, I had to know what access point I was logging into.

5:14And so I'd have to not only use static IPs, but I would have to document those static IPs so that when I looked at a diagram or maybe a spreadsheet, I could find the access point, I could get the IP address from that document, and then I could log into it that way. So as you can see, we had some problems that we needed to resolve. And this is where the lightweight architecture came into existence. The concept of the lightweight architecture was basically to do what this management solution down here was trying to do, but to do it in a much better way.

5:44One of the ways we did this, was we offloaded a lot of the configuration, meaning that the configuration is no longer managed by the access point itself, but is managed by, once again, a wireless LAN controller. At the time we didn't have cloud-managed solutions, and so we had to install a physical wireless LAN controller somewhere in the architecture. Now because this configuration was offloaded, this meant that a lightweight access point that couldn't find a wireless LAN controller basically meant that it was dead in the water. It wasn't able to do anything without connection to the wireless LAN controller.

6:18So we need to make sure these wireless LAN controllers stayed up, otherwise we'd lose our entire wireless domain. So the idea here is the lightweight access point would boot up, it would find the wireless LAN controller, it would download the configuration, it could even download the appropriate version of code that it's supposed to be running. And so there's a lot of advantages right away right here. But then the wireless LAN controller would continue to manage that access point as well. It would do things like tune the radios. It would decide which channel it should use based on interference.

6:50And so look at all the things I didn't have to think about anymore. I didn't have to worry about manual assignment of channels, I didn't have to worry about manually doing a whole, I didn't have to configure access points out of the box. I could simply plug them into the network. And importantly, we could rely on DHCP for this. I didn't have to worry about my static IP tracking anymore. And the reason for this is because me as the admin, I no longer log in to the access point. This doesn't happen anymore. Instead, I log into the wireless LAN controller, and so this needs a static IP.

7:23But then the wireless LAN controller is going to again push all of the configuration down to the access points, and it's going to track those for me, meaning that I don't care anymore what IP address the access points have. The wireless LAN controller will keep track of that, and it will keep track of that based on the fact that the access points are logging in to the wireless LAN controller when they boot. Doesn't matter what the IP address is at that point. And so this is why we can rely on DHCP. Now the other interesting thing about lightweight wireless LAN controller architectures is this concept of tunneling.

7:54And we'll go into a little more details about what that means coming up in the next video. But this concept only exists with wireless LAN controllers, it doesn't exist with a cloud architecture. So let's talk about that cloud architecture concept. The cloud architecture started to develop I would say in the late 2000. Really caught steam in the early 2010s. And the idea here was wireless LAN controllers introduce a lot of complexity. And we're going to see that here coming up. And so some of these vendors were showing up and saying, let's not worry about wireless LAN controllers anymore. Let's move that to our cloud system.

8:26This means that when an access point comes online it's going to log in to the cloud system, and it's going to do everything that the wireless LAN controller was doing for us. So there's still a controller at play here. But it's no longer a physical controller on my network. Instead it lives somewhere out on the internet, and the access points know how to find it from the beginning. So they simply boot up they connect to the controller. And the controller does all of the same things that the wireless LAN controller does with the lightweight architecture. Now cloud solutions, even though they don't have a wireless LAN controller, they are still a lightweight architecture, because once again, if one of these access points can't access the cloud controller then it's dead in the water.

9:08It gets its configuration from the cloud. It gets its management from the cloud. And so there's very little that these access points can do apart from accessing the controller environment. Now again, me as the network admin, I'm not going to log into the access points I'm going to log in to this controller and perform all of my configuration. And so these access points can once again, be DHCP, because I shouldn't ever have to log in to any of them manually. Now one of the beautiful parts about this architecture is the licensing element. Licensing is a big pain point on wireless LAN controllers.

9:40I might get a physical wireless LAN controller. And this physical wireless LAN controller can support up to 50 access points. And as soon as I have 51 access points in my environment, well, I have a problem, because I can't bring that 51st access point online. And this is not only tied to hardware, it's also tied to licensing, and redundancy gets really tricky because if that wireless LAN controller goes down, then I need another one, but do I need to wireless LAN controllers that both support 50 access points? It gets to be a little bit of a hassle.

10:10Well licensing with a cloud environment is very simple. All I need to do is license my access point right here to say, OK, I've got one license on this access point. And that's all I need to worry about because the controller environment scales up to as many access points as I need. Now the other aspect to be aware of as far as cloud-managed solutions are concerned is that we do not form network tunnels. And because we're not forming network tunnels for the data traffic, we're going to have to address layer two layer three roaming and some other things that tunneling can help us with.

10:42So there are definitely advantages to having the tunnels, but I will say that lacking the tunnels kind of comes back to this simplistic architecture. And for a lot of environments having a simple architecture matters more than maybe having a few features that tunneling might have provided. So autonomous access points, the start of our journey here going back in time, they had a major scaling issue. I had to log in each one manually. I had to make sure all the configuration was there. I had to manage each one individually once it was deployed. And again, once we talk about dozens and hundreds and thousands and tens of thousands of access points, this just wasn't something that was going to be able to last.

11:20And so the industry moved towards lightweight architectures, these lightweight access point can do nothing apart from a controller. But that controller can control all of the access points. And so it can do a lot of things automatically for us, and we don't have to worry about manually configuring as many access points anymore. And so this was a beautiful solution, but it did rely on a wireless LAN controller, usually a physical appliance that was installed somewhere in the network. Now lastly these cloud-managed solutions, still a lightweight architecture technically. But its controller is not on-site anymore.

11:52It's up in the cloud. And so access points plug in to the network. I license that access point. It just goes out it finds its internet-based controller. I log into a web-based client to configure it as the admin. And so I get a lot of the benefits of the lightweight architecture without having to worry about the hassle of the wireless LAN controller, and its redundancy concerns, and licensing and all of these things, just keeping in mind that we don't get wireless or data tunneling. And so we're going to talk about tunneling and the benefits of tunneling. But again, it is a more simple architecture.

12:24And so for a lot of people, that is what they care about the most. And we can figure out how to work around the tunneling thing by looking at other options there. I hope this have been informative for you. And I'd like to thank you for viewing.

0:00[AUDIO LOGO] Well, as we mentioned in the last video, wireless LAN controllers can introduce some complexities into our network. It's one of the reasons why some vendors have gone exclusively cloud and they tout the benefits and the simplicity of a cloud managed environment. But there are a lot of architectures out there today that still rely on wireless LAN controllers. Let's go ahead and understand what exactly a wireless LAN controller is and what some of these considerations are that we need to take when we're incorporating them into our designs.

0:31So as we've mentioned, a lightweight access point can do nothing apart from a controller. It's going to have to associate to some kind of controller in order to function, whether that's a cloud managed solution, or, once again, a wireless LAN controller. So what exactly is a wireless LAN controller all about? Well, wireless LAN controller can take on a lot of different forms, actually. So most commonly, we think of wireless LAN controllers as being a physical appliance. This physical appliance is going to get installed into a network rack, it has network ports, and it's going to be a little bit expensive because I have to purchase something that has a lot of hardware in it and 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 a monthly subscription. Now, we can take on other forms as well here. For example, a lot of vendors now offer a virtual appliance as well. The concept of a virtual appliance is kind of interesting. It's basically a software version of the hardware that appears here in the physical appliance. In fact, it's often the exact same software, whether I purchase a physical or virtual appliance. The difference is this is going to cost me less money. However, it also doesn't come with any hardware.

1:42There's a lot of hardware that I pay for in the physical appliance. And so I'm going to have to deploy this into my virtual environment, so I'll probably deploy it as virtual machines. And this is usually going to involve servers. And so I'm still paying for the hardware. I'm just paying for the hardware here. And then I can possibly share that server with other virtual appliances and such. So this is very commonly what people do these days. However, physical appliances definitely still have value, especially when it comes to tunneling. Now, this can also actually show up as an embedded concept.

2:16So we might see an embedded controller on the access points themselves. This is an interesting one because we just said lightweight access points require controller. So what are we talking about here? Well, what can happen is, if we've got a small site, I might have, let's just say, three or four access points here-- we'll say four. So I've got four access points. And do I really want to go out and purchase a physical appliance or a virtual appliance, some kind of wireless LAN controller, for this very small site? Well, maybe what I could do instead is I can use an embedded controller on one of the access points.

2:48A lot of vendors support this. Especially Aruba and Cisco are known for this. And so I can convert this access point here into a wireless LAN controller. In fact, it can play both roles at the same time. It can have an access point functionality still, while running the wireless LAN controller, oftentimes, as what we call a container service. So this basically just means that it's leveraging the hardware of the access point to run different software and usually built on some kind of Linux operating system. All that to say, what we're going to do is allow these other access points to connect to this access point over here, including itself.

3:25All four of these access points are going to connect to the wireless LAN controller instance that's running on that access point. And then for me, as the admin, I would still log in to the wireless LAN controller and configure my access points that way. That's a pretty cool option for sure, but it really is intended for smaller environments. So keep that in mind. Now, all of these devices are going to need network access, especially when we look at the physical and virtual appliances. And so a lot of these appliances will have 10 or 40 or even 100 gig connections to the network because as to facilitate all of the access points connecting to it.

3:58And the larger the scale, the more bandwidth we're going to need. Now, if I purchase a physical appliance, it's going to come with those ports. If I purchase the virtual appliance, then I'm going to need to provide these ports on the server, because we are going to need a whole lot of network traffic still, and this is where-- even purchasing a virtual appliance, we might end up paying for a lot of hardware that we maybe could have just purchased a physical appliance at that point for. But again, if we've got a server where we can share resources, then it does make sense to do so. Now, a big challenge with wireless LAN controllers is the discovery process.

4:31If I have a cloud-managed solution, the access point knows how to get out to the cloud because it's been preconfigured with this. This cloud connection is embedded in the code of the access point because this cloud system-- it never moves. It never changes. It's got the same IP address or the same DNS resolution no matter who's deploying the access points. But this, naturally, isn't going to work from a wireless LAN controller perspective because my wireless LAN controller-- it could be anywhere in my network. And because it could be anywhere, it could have any IP address.

5:04And so, we're going to need to come up with a little more sophisticated method for discovering the wireless LAN controllers as an access point boots. So the process is going to look something like this. The access point is going to boot up, and it's going to check its local configuration because it can store local information-- not necessarily channels or radio power because that's dynamic and depends on the wireless LAN controller-- but it can store local information such as, hey, where are my controllers, especially if I've booted up before? From there, we've got a lot of different options for finding our controllers.

5:38One of the most popular is going to be what we call DHCP and then option 43. When we do DHCP, this is our dynamic process for getting an IP address. And we already mentioned that lightweight access points can now use DHCP. And this is another reason why we'd want to do so. I boot up, I get an IP address from the DHCP server, but the DHCP server can do more than just hand out an IP address. Using one of these options, such as option 43, we can provide other information. And so option 43 allows me to provide a list of wireless LAN controllers.

6:09I can say, here's wireless LAN controller 1, here's wireless LAN controller 2, and maybe even here's wireless LAN controller 3. And so now I've got a primary, secondary, and tertiary controller that I add to my configuration. Now, if I'm not using DHCP or my DHCP server doesn't support option 43, even though it is commonly supported, we could look at another option. We could look at DNS resolution as another way of discovering the WLC. And so, oftentimes, each vendor will have a very specific name resolution to look for. And so maybe we'll try to resolve the vendor name, and then dash WLC, and then whatever our local domain is, which, by the way, we are getting the local domain as part of our DHCP process.

6:50And so I run a resolution against this name. And at this point, I can get a wireless LAN controller IP address. Now, I can only get a single wireless LAN controller IP here. And so that access point might connect to that specific wireless LAN controller. And then that WLC can pass down redundant to WLC as part of the process. So I can still get my list. I just won't get it as part of the DNS process. Now, another option that doesn't always work very well, because it requires a smaller network, is that the access points can also perform a broadcast.

7:22A broadcast message is only going to go within a VLAN or a layer 2 domain. And so, this broadcast is going to work just fine if the access point is connecting to a switch here, and the wireless LAN controller is also connected to a switch, and they're on the same VLAN. It's all part of the same layer 2 domain. That's going to work just fine to send out a broadcast. However, as soon as my network gets a little more complex, and now it actually goes through a router, a layer 3 domain here, to get to the wireless LAN controllers over here, let's say, and my wireless LAN controller is no longer associated or connected with that original VLAN, well, now, a broadcast isn't going to work.

7:58Because broadcasts only go as far as the layer 2 domain, and then they are cut off. And so, at that point, I'm going to have to use DHCP or possibly DNS in order to find the wireless LAN controller over here. Now, lastly, a lot of vendors do still allow me, as the admin, to do a manual configuration. And so, remember my example where I had all my access points on my desk, and I was moving my console cable around and configuring them. This still is an option. It's certainly not ideal. But it is something we could do. We could get in there. We could configure my list of access points-- or wireless LAN controllers, rather.

8:30I could do wireless LAN controller 1, WLC 2, WLC 3, and I can do that manual configuration on every access point. And it's just not going to scale. We give up scalability here, once again, because we're basically reverting to autonomous configuration. At least, it's only for the sake of finding a controller, but it is still manual. Now, once the access point does find the wireless LAN controller, it will connect to it. And it will form that tunnel, which we're going to talk about more in the next video Now, there are definitely some design implications that we need to consider because, well, vendors do still have wireless LAN controllers that are going to go into the network.

9:04And so that's going to impact our design in a number of different ways if that's the solution we're choosing to use. So we already talked about it. But we do need to consider licensing and generally sizing of the wireless LAN controllers because a wireless LAN controller typically will support some number of access points. Now, it varies by vendor. We might have a wireless LAN controller that just straight-up supports 100 access points. Or we might have one that can support 100, 150, or 200, depending on the licensing. And so, from a hardware perspective, it's limited to 200, but I might purchase it and, by default, it supports 100.

9:38And I would have to pay for more licensing if I want 150 or 200. But we still have to be careful. Again, any time we're talking about hardware, we'll have hardware limitations. And so, if I have to install a 201st access point, that's going to be a bad day. And so we need to take this into account. And we need to have growth factored into our design. Because if I have, let's say 185 access points today, this wireless LAN controller model will support that, but 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 or I just need to bolster up my wireless solution a little bit, then there's going to be growth involved. And I'm really risking a lot here because the wireless LAN controller is very expensive to rip and replace. We want that to last five or six years before we have to invest in hardware once again. We also need to consider failover. And so, I'll just write this out as redundancy. Redundancy is a big concern. Because if I have a single wireless LAN controller, and I've got a bunch of access points out here that are all connecting into that wireless LAN controller, what happens if the wireless LAN controller fails?

10:46At this point, I would hopefully have another WLC that those access points can resolve to. Again, we're typically providing a list, like we said, of several wireless LAN controllers for the purpose of redundancy. These access points need to stay associated with a controller. Otherwise, they will go down, and they'll take the Wi-Fi network down with them. And this is well and good other than wireless LAN controller redundancy starts to get a little bit complicated. Because is this per site, or is it for the entire organization? And furthermore, how do I license these?

11:17Let's say I have 35 access points. I decide that a 50-access point controller is good enough. Well, do I license both of these for 50 access points? Because now I'm paying for a lot of licensing that I'm never going to need. But at the same time, I need to support all 35 on one of those wireless LAN controllers in the event of a failure. Otherwise, I could load balance between them. Now, some vendors support the concept of hot standby which means that they share licensing, and so that issue can be resolved. But we do need to make sure that we are deploying a redundant solution.

11:48And furthermore, we need to consider where, on the network, the wireless LAN controllers will go. And we'll be talking about that as part of our tunneling conversation. So wireless LAN controllers, they are at the heart of a lightweight architecture. In a lot of cases, we're still deploying wireless LAN controllers as part of some of these solutions. So if it's not based in the cloud, it's going to be based in my network somewhere. And as we saw, that can take a lot of different forms, whether it's a physical appliance, virtual appliance, et cetera. Now, our lightweight access points, they have to discover the wireless LAN controller. Again, in a cloud solution, it's simple to do that because I just resolve my DNS or whatever.

12:22The access points are pre-configured with that, and they can go out and find the cloud. Whereas, with my network, they have no idea where the wireless LAN controller is. And so maybe we'll do DHCP option 43. It's a very popular option. We might do DNS. We might do broadcast. And so we've got a lot of different ways of doing that up to and including, potentially, manually configuring those access points, which is not ideal, but we can do it. Now, lastly, we've got to make a lot of design considerations here with wireless LAN controllers. We have to think about the form factor like we talked about. We also have to think about the licensing.

12:54We have to think about the redundancy. And so, there's a lot of different considerations we have to make as far as these wireless LAN controllers are concerned. We also have to consider where in the network we're deploying these. And so we'll find that the location of the wireless LAN controller matters a lot when we are tunneling our wireless clients. I hope that it has been informative for you, and I'd like to thank you for viewing.

0:00[AUDIO LOGO] We've mentioned several times that when a lightweight access point connects to a wireless LAN controller, it's going to form a tunnel, and that tunnel is known as a CAPWAP tunnel. In this video, we're going to explore the implications of these CAPWAP tunnels and why they matter so much, because if we're throwing our wireless clients into these CAPWAP tunnels, it is going to fundamentally change the way our network architecture comes together. And let's see this in action. We've mentioned that lightweight access points are going to need a tunneled connection to the wireless LAN controller.

0:33And this tunnel is going to be known as a CAPWAP tunnel. CAPWAP stands for the Control And Provisioning of Wireless Access Points. We're going to send three different types of traffic across this link. We're going to send control traffic, meaning that this is the access point basically communicating with the wireless LAN controller and staying online. We're going to have management traffic, which is controlling the radio frequencies and controlling the radio power and such. But then we're also going to send our data traffic. This data traffic being transmitted through the tunnel is what makes things interesting.

1:07And in order to understand why, let's talk about what a tunnel is. In networking you may recall studying the OSI model. The OSI model lists out a bunch of layers. We start at the physical layer, and data link layer, network layer, and so on and so forth. And the idea is that we are going to use the concept of encapsulation. Encapsulation says that I'm going to take a packet of information-- so I've got some amount of data, and then I'm going to take that data and put it inside of a header. And so I'm going to place this header right in front of the data, and it basically describes what to do with this data.

1:40But what's fascinating about this is I can take all of this information, including the header, call it data, and then I can put another header in front of it. So now, I have what was originally a header and a bunch of data in here, and now it has a new header in front of it. And this is exactly what we do as we move data from one layer to the next to the next within the OSI model. For example, I might have an IP header here, so this is a layer 3 header, and it's got the IP address in there, and everything's good there. But then I encapsulate that and put it inside of an Ethernet header.

2:13And the Ethernet header is going to have the MAC addresses and all of that. And so while this is a natural part of our networking process, where we have TCP headers and IP headers and Ethernet headers and all of these things, we can actually take advantage of encapsulation and put it into a process that we call tunneling. Tunneling is typically when we encapsulate within the exact same header. So for example, I might have that IP header that I just mentioned. It's got an IP address and everything in there. And then it's got a bunch of data.

2:43And normally, I would encapsulate this in Ethernet and send it across the network. But I can take this as data, and I can put another IP header in front of it. And this IP header is going to direct this amount of information out towards another location. It allows me to essentially rebound traffic. So if a source starts out here, and the destination is over here, I can have two IP addresses. I can have the outer IP header that says, hey, I want you to go up here to this device, whatever that device is.

3:16This device de-encapsulates it, looks at the inner IP header and says, oh, you really want to go down here to this destination. Now, why I would want to do this, there's a lot of reasons for it. For example, this could be a firewall, and I want to inspect that traffic before it goes to the destination. Or hey, guess what, in the wireless world, this could be a wireless LAN controller. And I know that this wireless client down here is trying to communicate with some destination out on my network, whatever that is. But that traffic needs to go through the wireless LAN controller first.

3:47And so this is why we call it tunneling, because all of the devices that are in the path here, the switches in these routers, they have no idea that you're trying to get to this destination. I just know that you're trying to get to the wireless LAN controller up here, and so I'm going to forward you towards that destination. Now, this is why the location of the wireless LAN controller starts to matter a whole lot, because if I'm tunneling my wireless client to a different location, well, my wireless clients might as well be attached to this wireless LAN controller physically.

4:17Yeah, it's not physically attached there. It's physically attached to the access points down here. However, this is what we call our logical point of presence. The client is going to show up on the wireless LAN controller and then get forwarded down towards the destination. So as far as the network is concerned, it only sees the client show up at the wireless LAN controller. Now, this has some implications. For example, let's say that I have an access point here, and it's connected to a switch, and that switch goes through a firewall.

4:48And that firewall is going to connect me then to, let's say, the data center. Let's say we're firewalling all of the traffic, making sure that all of our applications and data, they're all safe in the data center. We want to inspect everything here. Life is good. We're forwarding traffic in and out of there. And then I've got my wireless LAN controller inside the data center. Well, here's the problem. If I've got a client that attaches to this wireless access point, and then the access point sends it through the CAPWAP tunnel to the wireless LAN controller, look at what we just did.

5:19We just bypassed the inspection of that firewall, because we embedded it inside of the CAPWAP tunnel. The firewall does see that traffic. However, it sees it as the source being the access point and the destination being the wireless LAN controller. By default, it's not going to look inside of that IP packet and see that there's more header information within. And so now what we have is a wireless LAN controller that's connected in through a switching infrastructure. And maybe we've got our servers down here. And so what ends up happening is the servers are attached to the switching infrastructure, and I'm placing my clients directly into that switching architecture.

5:56And once again, those clients have fully bypassed the firewall in the middle. So we have to be very careful about where we place the location. And the question is, where does the wireless LAN controller belong in the network? Well, in a lot of cases, we would recommend that it goes into the distribution layer. The distribution layer is part of our network architecture. We're going to find that we've got a network core here. We've got maybe the data center hanging off over here. We maybe have our wide area networking hanging off it as well. And then on a per-building basis, we usually have a distribution layer that connects to the access layer.

6:30And we already mentioned that the access layer is where all of our access points connect. And so we know that part. But now we're suggesting that the wireless LAN controller be connected here at the distribution layer. The distribution layer and the access layer, these typically form a single layer 2 domain. And so that keeps our clients within the same layer 2 domain in the same IP addressing space. It also makes sure that our clients don't magically show up over here in the data center, and they pop into existence. It's like we teleported them almost, and in doing so potentially bypassed security measures.

7:02The reason why I keep bringing up the data center is because I've seen a lot of wireless LAN controllers get deployed into the data center, which makes sense. This is a highly resilient, highly redundant environment. We have server racks. And that's exactly where we need to deploy our wireless LAN controllers. And if we're going to deploy wireless LAN controllers for the entire network, well, at this point, it makes sense to deploy something that we might consider global into our data center. However, despite all of these advantages, it really is better to deploy our wireless LAN controllers into the distribution layers for their associated buildings.

7:35Now, herein lies the challenge of the distribution layer though. And a lot of organizations have many distribution layers. And so I've got another building over here that has its own set of distribution switches and access layer switches. And so maybe this is my headquarters building here, but maybe this is my remote site, or a branch office, and then I might have a lot of these branch offices. So do I need wireless LAN controllers here as well? Well, with this architecture, we would. And so we would spec out our wireless LAN controllers to go at every site.

8:06But then we'd have to consider a redundancy, and so I need maybe a second wireless LAN controller at each location. Or potentially, I could rely on the other site for my failover in case a wireless LAN controller goes down. And so there's a lot of conversations to be had here. But as far as a clean network drawing or clean network architecture with wireless LAN controllers, this is typically what we're going to aim for. And then we can adjust accordingly based on the needs of the network. Now, if we were to decide, hey, we've got so many locations. We really need this global concept. We've got a couple of options.

8:37We could deploy it into the network core, although we don't like to deploy anything to the network core other than just the core switches, and so that's not very ideal. And the other option is we do deploy it into the data center. However, we would want to deploy it into a part of the data center that is still firewalled and isolated from the rest of the data center networks. Now, there are a couple of benefits to deploying this tunneling mechanism, because we could say, you know what, the tunneling is no good. I want to shut it down. A lot of vendors will actually say, hey, you don't like this idea?

9:09Let's just go ahead and get rid of the data traffic. We'll drop that off locally like any other solution would. And we'll only send control and management traffic across the line. And so that's certainly an option, something that we could do if the CAPWAP tunneling gets too complex for us. However, again, there are reasons why we'd want to leave it in place. One of the biggest ones is the elimination of layer 3 roaming. Layer 3 roaming is a highly disruptive form of roaming that occurs when I have an access point here advertising an SSID, an access point over here advertising an SSID.

9:41And I want to roam from one access point to the other, but there's a layer 3 boundary in the path. And so if this is the case and I'm actually roaming between layer 3 domains, I have to change my IP address. And if I have to change my IP address, again, that is a super disruptive operation. And for example, any phone call you're part of is going to drop. Well, by tunneling, again, we kind of ignore the underlying infrastructure. We are bypassing even layer 3 devices like we bypassed our firewalls. And so it actually eliminates the concern with layer 3 roaming.

10:13And so we can still have these layer 3 devices, whether that's layer 3 switches, or routers, WAN circuits, et cetera. We can have that in between our access points, and we don't need to worry about changing IP addresses. So that's a huge benefit. That would be number one. The second benefit is a callback to the concept of our guests being forwarded into the DMZ. I mentioned earlier that this tunneling concept can be used for this. And that's a great way to do it, because if I place now my WLC into the DMZ near the internet, at that point, my guests get forwarded directly into the DMZ simply via the CAPWAP tunneling.

10:47And so it's an automatic way of doing things, whereas without CAPWAP tunneling, this architecture would be very complex to deploy and manage. So this concept of CAPWAP tunneling, it's going to send all of our management, our control, and our data frames by default to the wireless LAN controller. And this has some heavy implications. For example, where in the network do we want to deploy the wireless LAN controller? If we deploy it into, for example, the data center, we might bypass firewall inspections, because tunneling truly hides the data traffic until it shows up after it has been de-encapsulated.

11:20And so it teleports our clients wherever the wireless LAN controller lives. And so we'd probably want to consider deploying our wireless LAN controllers into the distribution layer if we can. However, it's going to be a case-by-case basis. Now, tunneling does have its benefits. So even though we could opt to maybe get rid of the tunneling altogether, even in vendors that typically support wireless LAN controllers and CAPWAP tunneling. We would not necessarily just want to do that, because it does help with layer 3 roaming. If that's a concern in our environment, and you can roam between layer 3 domains, then we'd probably want to keep this tunneling in place.

11:51It also helps us with the concept of anchoring our guests into the DMZ. And so there are definitely benefits to deploying our CAPWAP tunnels. We just need to decide if it makes sense or if it's better to go with a nontunneled solution and maybe even go with a cloud controller at that point so that we just don't even have to worry about the wireless LAN controller. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[AUDIO LOGO] Sometimes, in the wireless world, we're not even worried about our wireless clients anymore. We are simply going to use wireless to connect our network to another network, usually one that we also own. For example, if I've got my headquarters in this location and I just purchased an office building maybe down the street, I could potentially, rather than tying into expensive fiber, monthly charges and all of that, I could potentially put a wireless bridge up on both sides and communicate wirelessly with one another.

0:33It's a great way to deploy cost-effective wide area networking and connect my disparate networks together. So in this video, we're going to take a look at what exactly it looks like when we perform wireless bridging, as well as what some of the considerations we need to make are as part of our wireless designs. We often think of Wi-Fi as being used to connect clients to the network. But wireless can be used as a form of wide area networking, or what we would call the WAN. Wide area networking is designed to basically connect our local area networks together. So I might have a LAN at one building, a local area network at another building.

1:03And I'm going to go through this wide area network in order to connect the two. And there are a lot of different options out there. I could get some fiber connectivity. I could certainly go through a service provider, maybe get an MPLS circuit, but there's a lot of different circuit types out there. However, wireless bridging is a very interesting proposition. The reason for this is usually these options are very expensive up front, and they require some amount of spend per month. If we have to spend per month, this is going to add up over the long run as well.

1:35Whereas wireless, this is a one-time spend. I purchase hardware that I can mount on both locations, and then that hardware communicates with the other hardware, and I don't have to pay anybody anything a month because I've set this up and I'm running it myself. Furthermore, bridging can be point to point-- meaning I have two bridges pointing right at each other-- or it can be point to multi-point. Point to multipoint means I might have an HQ here, and maybe I have some sort of campus. And so I've got a lot of buildings out here that I want to connect to.

2:06Well, I could deploy one wireless bridge here-- draw this as a tower, sort of a beacon I suppose-- I've got one bridge up here, and I'm communicating with all of these other bridges at a time. And so that further reduces the complexity of my network and reduces the amount of hardware that I have to spend. Now, the way this is typically going to work is I'm going to have my building here and a building over here, and I have to try to get my wireless signal across from one building to another. This is going to involve what we call line of sight networking. I'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, that's not going to work in the same way that if there's a bunch of buildings in the way-- maybe this is a metropolitan area-- I'm not going to be able to make that work either. And so I'm going to want to mount my bridges as high as possible. So maybe I mount it to the side of the top floor of my building if the buildings are tall enough. However, if they're not tall enough, I might actually install a wireless tower outside. And so, by the way, these could be miles apart. I know I've got them drawn sort of right next to each other, but maybe I've got my two wireless towers now built, and I mount a bridge on the top of each one of these.

3:11So, yeah, building a tower is certainly going to increase the cost of the solution. But again, I'm not paying anybody per month, and so it makes a whole lot of sense to do this. And furthermore, burying fiber between these locations would certainly not be free either. And so, at this point, I'm communicating to one another wirelessly this way, and I run a network connection down off of each wireless bridge and connect it into my switching infrastructure. Now, line of sight is good, but we absolutely have to understand the concept of what we call the Fresnel Zone. The Fresnel Zone is a three-dimensional space that exists outside of line of sight.

3:46And so, let's say we have two wireless towers once again. And so, we've got wireless bridges at the top of each one of these. And so, I am now going to be pointing my antennas or my bridges at one another and in most cases, I would assume that if I can see each other and I've got line of sight all the way across, then I'm good to go. Even if there's a tree right here, as long as I can get across to the other side, I can see the other side, then I should be good. But this is not how physics works, at least as far as our RF signals are concerned.

4:16Instead, the wireless signals are actually going to form this three-dimensional oval shape. And so, this oval shape is, once again, three-dimensional, and it needs to stay clear. This means that a tree that grows into this Fresnel Zone space, even though it's below line of sight, it's still going to cause me wireless problems. And so I have to be really careful about this for a couple of reasons. First of all, I might expect that line of sight is the only thing I need to worry about. But the other concern is there might be some very low trees down here and we run our calculations and we say, OK, everything's good because the Fresnel Zone is empty or clear.

4:52However, trees grow over time. And so, a couple of years later, we might find that this tree is no longer that short and it's actually starting to poke into the Fresnel Zone here. Now, there's still a lot of grace to be shown in the Fresnel Zone. I mean, we want the Fresnel Zone, ideally, to be 100% clear. Certainly, that is the ideal. However, from a wireless performance perspective, if we can have 60% be clear, then we would call this acceptable. It's acceptable because we are still able to get our wireless signal through with enough performance for the wireless network to give us what we need.

5:26Now, one other problem in all of this that we might need to consider is the Fresnel Zone's impact with the Earth bulge. The Earth is round. And this is one of the ways that we know the Earth is round, because if I build a tower here and I build a tower that's really far away, typically across great distances, then I'm going to have problems even if I'm looking at-- again, I see line of sight here, but even if I draw the Fresnel Zone, this might become a problem because the Earth being round can actually poke into that Fresnel Zone.

5:58Now, we just said that 60% clear is acceptable. However, naturally, the Earth bulge is going to matter more on longer distance links. For example, if I've got a really long distance link and this is many, many miles, well, now I might have a tower here that, yeah, we've got line of sight with each other like this. But as soon as I start to draw the Fresnel Zone, we see that there's a big problem with this. And we've got more than 40% potentially being blocked by the Fresnel Zone, especially if now we talk about there being some trees in the path.

6:30Maybe there's a forest in between here. And so the Earth bulge is only going to be something we need to worry about if we're over roughly 7 miles, which is 11 kilometers. And so, if you've ever heard the company 7-Eleven, that's a way to think about this, I suppose-- 7 miles or 11 kilometers. If we're over that, then we are going to need to factor in the earth bulge into our Fresnel Zone calculations and make sure that we are building our towers higher than we would have built them otherwise. So this concept of wireless bridging-- it's an application that's going to allow us to extend our networks from one site to another without having to go through a service provider or bury fiber or anything like that.

7:08We can simply mount wireless bridges to the buildings, or possibly towers, and connect to each other that way. Now, even though line of sight sounds good on paper, we need more than just line of sight. And the physics really starts to get involved here, and we need to keep the Fresnel Zone clear. The Fresnel Zone is this three-dimensional space around the line of sight line that-- if we can keep it at least 60% clear, we should be good to go. Naturally, we want to keep it as clear as possible, and the more we keep it clear, the fewer re-transmits and such we're going to have.

7:39Now lastly, we've got to consider the Earth bulge when it comes to long distance links. The curvature of the Earth starts to impede potentially on that Fresnel Zone. And so we've got to keep it clear once again. And if a link is over 7 miles or 11 kilometers, this is where we would need to factor the Earth bulge into our account and make sure that our towers are taller, or maybe our bridges are mounted taller, at least regardless of how we do that, in order to account for the bulge. I hope that it has been informative for you, and I'd like to thank you for viewing.

0:00[AUDIO LOGO] All right, the skill is done. So it's time for that review to make sure we've got it all down. First up out of four questions, how does licensing work with a cloud-managed wireless solution? So when it's cloud managed, we don't need to worry so much about licenses on a controller basis, that kind of thing. However, we are going to need a license but where that's going to be mapped to each individual access point.

0:31So if we want an access point to be part of the solution, then we would license that access point. In a cloud-managed solution, we don't actually have wireless LAN controllers. Saying each cloud requires one license is going the wrong direction here. We usually only have one cloud solution. And it's certainly not licensed for-- at least, in my experience-- maybe some vendor out there has a license for each solution. But usually, you are paying a per-month or per-year license per access point that's part of the solution. Next question, which of these discovery methods requires a wireless LAN controller to be on the same VLAN as the access points?

1:08Well, the only one that's going to require that we all be on the same VLAN would be the broadcast option, because a broadcast is contained within a VLAN. That's the nature of a broadcast message in networking. All of these other options are going to be able to allow access points to connect to the wireless LAN controller wherever it is. And as I've mentioned during the skill, DHCP Option 43 is typically our most popular option because it gives us that list of controllers to start with. And it happens as part of the DHCP process rather than having to do anything other than simply getting a DHCP message back.

1:40Question three, what is a concern with deploying wireless LAN controllers into a sensitive part of the network such as the data center? Our big concern here is that our wireless clients are getting tunneled via CAPWAP into wherever the wireless LAN controller lives. And so if we're going into the data center, well, that data center might have a firewall in the path. But because the wireless LAN controller lives here and we have our wireless clients out here that are communicating with it, they will get tunneled into the data center via CAPWAP.

2:13So let's make sure we're very intentional about where we're placing our wireless LAN controllers. They could physically go into the data center, so long as they logically are segmented from data center traffic. All right, last question, wireless bridging falls into which networking category? So we've got local area network, wide area network, metropolitan area network, and personal area network. The answer here is going to be B, wide area networking, because wide area networking is all about connecting our local area networks together, like we had mentioned.

2:46So I might have a bunch of local area networks out here, a bunch of buildings that all have their own switches within them, connecting to access points. And we need to connect all three of these together. And so we could do this via wireless. And that's exactly what the wide area network is supposed to do for us is to connect these disparate local area networks together. And with that, this quiz is done. If you didn't quite connect the dots on some of these concepts, then be sure to go back and review the materials in order to get it all down. Otherwise, congratulations on completing Define Wireless Network Architectures. I hope this has been informative for you, and I'd like to thank you for viewing.