Hello and welcome back. My name is Tyler McMinn with Aruba, a Hewlett Packard Enterprise company and this is the Aruba mobility essentials part 2, the fourth video in a series part 2, where we're going to be diving into the wireless LAN architecture. What are your options when it comes to setting up, not just a home network but an enterprise network? Up to this point, we really just looked at smaller, single AP deployments here, now we're going to step into a bit into the world of enterprise. I'm going to go over this lightly, we're not going to get too in depth because that really steps into the world of our associate level and professional level and expert level series of courses that take days and days. In this instance, we're just going to summarize what are the main options that a wireless vendor would choose from depending on what their needs are. Lets jump on in and get started. All right, so wireless LAN architectures; let's start with the basics, you've got a single access point, no controllers, nothing else, is just this stand alone or thick or what we would call in some cases fat AP; fat in a good way in that it holds all the intelligence it needs in here. If you look at like a NETGEAR or a Belkin or something like that that you might have at your home along those line, a NETGEAR can only act as a standalone access point, whereas something like Aruba AP like the one I'm holding in my hands here, these APs can join other standalone access points, or they can be provisioned to join a wireless controller like the 7210 that I have here on my floor. With autonomous mode APs the reason why we call them standalone or fat or thick provisioned APs, is that everything is done on the access point itself, and if you need to cover a campus wide full of devices where you might need 1,000 APs or 10,000 APs, having to provision each and every single one of these through a browser can be tedious, full of errors, difficult to troubleshoot and is generally just not a recommended practice to do that. It works okay in home environments, small offices with maybe six APs or less, but as you start to get beyond that, this is not a great option. Each AP is manually configured, each AP stores its own configuration, and originally all APs we're autonomous but over time, what we found was having either one access point acting as the intelligence, and then controlling all of the other APs was a good option to where you could just centralize the management itself rather than what you're going to see here where you have your laptop or whatever, your access point bounce in there, and then you've got to connect to it through the wire or wireless to get it set up and get a provision, so not the greatest way to go. What we moved towards was either clustering our standalone APs, which essentially allowed your other access points to be managed through a controller or what we call a virtual controller, and this is available today with our instant APs or our standalone APs from Aruba, they call them instant access points. You put up to 100 of these or so in the same site, the same network, the same local area network, and if they discover each other, because there's hard of the same virtual LAN, then one of them will automatically be elevated or elected to control all the rest, so you connect to one IP address and make a change and it impacts all of the other 100 access points in that cluster. But traditionally, what we would do is use our APs with a controller, like an actual physical controller rather than a virtual pretend controller running on an AP. With Thin access points, these allow them to be managed through the use of a wireless LAN controller. Thin access points as opposed to thick or standalone, thin access points, they receive their configuration from a central management platform. In many cases, the central management platform would be what you would call a controller, like the 7210 that I have here down on my desk. But if you want to see a quick example of what these controllers look like, you could do a simple Google search for, let me pull this up. How about Aruba controllers. That sounds pretty good. When I pull up Aruba controllers here, you'll see a nice little marketing [inaudible] and all that. But there you go, you've got the new nine thousand series, the 72 hundreds like the 7210 that I have down there, or the lighter and older seven thousand series, but still work great. Still take the most updated version of code [inaudible]. These are more for out to about 60 APs, whereas the 72 hundreds, you can put on two thousand access points. Two thousand access points could be fully managed by one controller, if you want it to. Very beefy high performance devices here. The other option, is you can manage APs through the use of the wireless controller [inaudible] , but you can also tie them into some network management system, or wireless network management system. In Aruba, we have a product known as AirWave. It works with command line templates and SNMP. It's a little older to do it this way. You're going to get a much more turn-key solution through the use of a dedicated controller, with a block of thin APs that is managing, because everything you do is through the controller, and the APs themselves are extensions; radio extensions of that controller itself. Another option, you could do the virtual controller. This is the Aruba Instant option that I was talking about earlier. Not really a cloud option, it's actually this one right here is the Virtual controller. What that really mean, is you have a bunch of APs at the same site. They elect one of their own to be their leader basically, which means you still have one point of management, like you would with the wireless LAN controller. One point of management, or like you would with AirWave, one point of management. You can use AirWave in conjunction with both of these, if you wanted to, where AirWave could push settings to a controller, or it could push settings to clusters. That's fine. If you would prefer not to have to house servers or large switches, and have to learn how to operate these, they're not terrible, there's a lot of easy wizards NMS and stuff like that. You might opt to go with something a little more robust than APs that talk to themselves. You might go with Cloud management through a service known as Aruba Central. This is very popular with small businesses, in that, you can simply purchase the APs themselves, and then there's a small annual fee to be able to have all your management, all your features in the cloud hosted by Aruba. This means you don't have to house anything on [inaudible]. It's a really good option when you have a handful of APs at a bunch of locations like coffee shops, or restaurants, or small hotels. As long as they have internet access, they can receive their configuration to this Cloud Aruba Central service. On top of that, you get all the benefits of a Controller of AirWave, you get the mapping, you get the support, you get Cloud services that you wouldn't get anywhere else. If you do not want to house things in the Cloud, then what a lot of people do, is they go with the instant AP options, through the Virtual controller cluster, or they go with a smaller wireless LAN controller. Those are the main features that you'll see from Aruba; the main deployment options that we go with. You can see how they scale. If you need tens of thousands of APs, you're going to put a cluster controllers at that site to manage those APs. If you need a few dozen APs, and you don't want to pay for, or have any kind of Cloud connectivity, then Instant APs with the Virtual cluster is the way to go. If you have a lot of smaller locations all over the place, you don't really have support that can drive around and fix these and configure them, then using the Central is a really good option. All right, the wireless controller managed AP's, they were originally called wireless switches, then the wireless LAN and AP configuration was all made centrally through this Aruba, or this mobility controller solution. This is a very common solution that you'll see among most vendors. What's a little bit different with Aruba, is that we have a server or virtual machine that you could run to manage multiple mobility controllers. If you have clusters of these, if you have controllers in different buildings, in a large campus or in different locations, all of those can be managed through one central pane of glass, if you will, through what's called the Mobility Master. It gives you a lot of scalability. The APs themselves would then tie in with the Mobility Controller. One way or another, they need to be connected in order to receive their configuration as well as to tunnel their traffic back and forth to the controller. You could choose to bridge your traffic. If you didn't want your wireless traffic to tunnel back, you could choose instead to bridge it and just run it right out to the internet, that's fine. Just depends on what deployment option that you want to use. This idea of tunneling, which is the default mode, tunneling simply takes the user traffic off the wireless and then forwards it along. You've got a user over here and what we'll see is we'll set this up where the user connects up, their data is encrypted at the user level through WPA2 or WPA3, we'll talk more about that in a bit, and then stays encrypted all the way through this tunnel until it gets to the controller. This generic routing encapsulation protocol is just a simple, simple tunnel from the source IP address of the access point to the destination address of the controller. It's a simple GRE tunnel with a payload itself encrypted from end-to-end. So no fear of anybody, if they were to capture this traffic, of being able to decrypt that; anymore than they could if the intruder was within wireless earshot and was capturing your frames, they wouldn't be able to decrypt it there where that would be much more likely a place to be attacked. The bridge mode bypasses the controller and instead the traffic is encrypted as you would expect on the user, but then decrypted, as you commonly see with other vendors, decrypted at the AP and then forwarded along to the internet and it doesn't go through the controller itself. There are some instances where traffic it makes more sense to only encrypt it at the site and then decrypt it the rest of the way. Just depends on what your scenario looks like. With Virtual Controllers, you have this cluster of APs, instant access points, that do not use a controller at all. This is just a regular switch, it's not a controller, and these guys will elect among themselves one Virtual Controller for management purposes, but otherwise, all your traffic wirelessly gets encrypted and decrypted at the user and at the AP. There's no tunneling involved here; it all just goes out to the internet, it doesn't go through the VC, only management traffic and your configurations do that. Then finally, the example of cloud-based. We have a Cloud Management Server in our central, you have across the internet access to these other multiple sites or maybe small restaurants or hotels or whatever, and all you need to do is open up your app on your phone or login to your central website or whatever and you've got live update access of all these devices. No tunneling goes to the Cloud, it's just stats and information to present to you and just your account about what's going on in your network. You get a lot of features by using this central service. It's automatically updated. You can manage not only the APs but the Aruba switches themselves. It's a nice, very much a turnkey solution. I think that's pretty much it. Autonomous APs are those standalone APs like at your house. Thin APs, those are access points that must connect to a wireless controller. One nice thing about Aruba APs is that they come with universal image. When you first boot them up or you reset them, you have a choice to at boot wirelessly connect or use the Aruba app on your phone to connect to them, and then you can choose, I want this to be a standalone instant AP and join a cluster, or I want this to be a thin AP, go find a controller or join central. You could join central as well. It's able to switch those images. Wireless controllers, they're going to manage your wireless traffic by either tunneling it from AP to controller or bridging it right out to the internet bypassing the controller. You still get your stats, you still manager your APIs, but your actual user data doesn't go to the controller. Then virtual controlled managed APs, those are basically the instant APs. They are standalone APs from Aruba that are able to cluster with other standalone APs at the same site at the same location. So very simple deployment. Lot of features but not as much as you would get with something like Cloud managed APs with central, definitely worth checking out there. Anyway, I know that was a lot. That was a summation of two days of our Mobility Fundamentals class. Those are good terms to keep in mind because not only a Aruba, but you'll see this strategy deployed by a lot of other vendor's. Not all of these do it, but Aruba does all of these. I hope you guys enjoyed that. I'll see you guys in the next video. Thanks again.
