WEBVTT 0:00:02.860000 --> 0:00:07.760000 Hello and welcome to this video titled Wireless Land Controller Deployment 0:00:07.760000 --> 0:00:11.960000 Options. In this video I'm going to be talking about Wireless Land Controller 0:00:11.960000 --> 0:00:15.180000 Deployments. We're going to focus primarily on things called the centralized 0:00:15.180000 --> 0:00:17.840000 wireless network architecture. 0:00:17.840000 --> 0:00:21.280000 I'm going to talk about something called FlexConnect, which is a way to 0:00:21.280000 --> 0:00:24.580000 make the centralized wireless network architecture work a little bit better 0:00:24.580000 --> 0:00:26.680000 in some situations. 0:00:26.680000 --> 0:00:30.560000 We're also going to talk about the converged wireless network architecture. 0:00:30.560000 --> 0:00:33.240000 By the time we're done here, you'll understand the difference between 0:00:33.240000 --> 0:00:36.420000 all three of these. 0:00:36.420000 --> 0:00:41.700000 In this video we're primarily focusing on on-site deployment of wireless 0:00:41.700000 --> 0:00:43.140000 land controllers. 0:00:43.140000 --> 0:00:46.560000 As you can see here, there's two methods or two options for this. 0:00:46.560000 --> 0:00:50.620000 You can do what's called centralized, or you can do a converged architecture. 0:00:50.620000 --> 0:00:55.620000 Like the last bullet point says, each architecture has a different approach 0:00:55.620000 --> 0:00:59.680000 to how data frames will be forwarded. 0:00:59.680000 --> 0:01:02.740000 Let's start with a centralized architecture. 0:01:02.740000 --> 0:01:07.460000 This typically means that you have one, maybe two controllers placed in 0:01:07.460000 --> 0:01:09.440000 a central location. 0:01:09.440000 --> 0:01:12.940000 That central location, for example, could be in your data center somewhere, 0:01:12.940000 --> 0:01:16.680000 but a central location of your company, and all your wireless access points, 0:01:16.680000 --> 0:01:20.040000 whether they're within that building, other buildings, or even at remote 0:01:20.040000 --> 0:01:24.380000 sites connected via a WAN or internet connection, have to come back and 0:01:24.380000 --> 0:01:30.080000 form their CAPWAP tunnels with that one or two centralized controllers. 0:01:30.080000 --> 0:01:35.500000 Now this maximizes the quantity of APs each controller can control. 0:01:35.500000 --> 0:01:39.100000 So clearly to do this, we're going to need controllers that can support 0:01:39.100000 --> 0:01:44.400000 more quantities of access points, that have more memory, more CPU power, 0:01:44.400000 --> 0:01:46.320000 so they can handle this. 0:01:46.320000 --> 0:01:51.700000 Now the positive side of this is that if all of my access points are connected, 0:01:51.700000 --> 0:01:55.940000 or I should say managed by one controller in a data center, I've got full 0:01:55.940000 --> 0:01:58.100000 visibility to everything. 0:01:58.100000 --> 0:02:02.240000 Once I log into the GUI of that particular controller, I have full visibility 0:02:02.240000 --> 0:02:04.700000 to my entire Wi-Fi environment. 0:02:04.700000 --> 0:02:08.120000 I don't have to jump from one controller to another, or Heaven's forbid, 0:02:08.120000 --> 0:02:12.560000 from one autonomous access point to another to actually see what's going 0:02:12.560000 --> 0:02:14.640000 on in my Wi-Fi environment. 0:02:14.640000 --> 0:02:18.080000 Now here's the thing you've got to be familiar with. 0:02:18.080000 --> 0:02:20.820000 Remember that in this environment we're talking about your lightweight 0:02:20.820000 --> 0:02:25.980000 access points building CAPWAP tunnels, two of them, to the controller. 0:02:25.980000 --> 0:02:30.100000 You've got a CAPWAP tunnel for the management and control data, and another 0:02:30.100000 --> 0:02:34.740000 CAPWAP tunnel for the actual user data from two and from the Wi-Fi clients 0:02:34.740000 --> 0:02:39.640000 themselves. Now, depending on how far away that centralized controller 0:02:39.640000 --> 0:02:43.340000 is from the lightweight access point, we might have to be concerned with 0:02:43.340000 --> 0:02:47.200000 the round-trip delay between those two, because traffic is going to have 0:02:47.200000 --> 0:02:49.420000 to go up that tunnel and then back again. 0:02:49.420000 --> 0:02:52.600000 So as you can see here, the design guidance is that the round-trip time 0:02:52.600000 --> 0:02:57.500000 should be 100 milliseconds or less between the lightweight access point 0:02:57.500000 --> 0:03:00.240000 and that centralized controller. 0:03:00.240000 --> 0:03:03.220000 So we can see right here, that lightweight access point, if we measure 0:03:03.220000 --> 0:03:08.400000 the time from it to send a frame, any kind of frame, data or control to 0:03:08.400000 --> 0:03:11.620000 that controller, which in this case is in the data center, should be 100 0:03:11.620000 --> 0:03:13.780000 milliseconds or less. 0:03:13.780000 --> 0:03:17.980000 Now, where you place that controller could also be one of two places. 0:03:17.980000 --> 0:03:20.600000 This is a very popular location right here, but you really have to ask 0:03:20.600000 --> 0:03:26.480000 yourself, okay, of all my Wi-Fi clients are connected via Wi-Fi, where 0:03:26.480000 --> 0:03:29.600000 is most of their data going to go? 0:03:29.600000 --> 0:03:34.080000 In other words, is most of the data from my Wi-Fi clients destined for 0:03:34.080000 --> 0:03:36.520000 servers in my data center? 0:03:36.520000 --> 0:03:40.500000 If that's true, then the controller should be placed there in the data 0:03:40.500000 --> 0:03:43.460000 center. Or an alternative approach might be this. 0:03:43.460000 --> 0:03:46.620000 You might say, well, hey, actually, most of the destination of my traffic 0:03:46.620000 --> 0:03:50.820000 is leaving my company and going out to the Internet, not necessarily going 0:03:50.820000 --> 0:03:53.020000 to my own local data center right here. 0:03:53.020000 --> 0:03:56.640000 So in that case, in a centralized wireless architecture, you might want 0:03:56.640000 --> 0:04:00.320000 to have the controller actually place closer to your WAN router that has 0:04:00.320000 --> 0:04:02.060000 your internet connectivity. 0:04:02.060000 --> 0:04:07.280000 All right, so let's talk about some pros and cons of the centralized architecture 0:04:07.280000 --> 0:04:11.320000 approach. So, benefits. 0:04:11.320000 --> 0:04:15.200000 By having one single controller placed in the data center or close to 0:04:15.200000 --> 0:04:18.580000 the internet access point, this is good because we're going to assume 0:04:18.580000 --> 0:04:23.080000 that most of your client data would need to reach that point anyway. 0:04:23.080000 --> 0:04:25.720000 So we're just going to tunnel it through most of the network because most 0:04:25.720000 --> 0:04:28.820000 of our network is never going to need to see that data, and we're going 0:04:28.820000 --> 0:04:33.200000 to pop it out of the CAPWAP tunnel at the other end real close to where 0:04:33.200000 --> 0:04:36.760000 that destination is that those clients are trying to reach anyway. 0:04:36.760000 --> 0:04:38.620000 Now, here's the drawback to this. 0:04:38.620000 --> 0:04:41.340000 And unfortunately, there are several. 0:04:41.340000 --> 0:04:45.620000 Number one, we know that all the wireless LAN client data must pass through 0:04:45.620000 --> 0:04:50.020000 that CAPWAP data tunnel before it can be placed natively onto the wired 0:04:50.020000 --> 0:04:54.760000 network. Now, that might not be a good option for several reasons. 0:04:54.760000 --> 0:04:58.880000 Number one, if that's a long stretch of routers and switches we need to 0:04:58.880000 --> 0:05:03.320000 go through to get from the lightweight access point to that controller, 0:05:03.320000 --> 0:05:07.580000 that could induce a lot of delay of that CAPWAP encapsulated traffic. 0:05:07.580000 --> 0:05:10.680000 And we want to keep that delay really, really short. 0:05:10.680000 --> 0:05:13.420000 Round-trip 100 milliseconds or less. 0:05:13.420000 --> 0:05:16.960000 That's round-trip there and back again. 0:05:16.960000 --> 0:05:22.980000 What if we had, now this doesn't happen a lot, but what if we had a situation 0:05:22.980000 --> 0:05:27.940000 where Wi-Fi clients within the same cell, within the same BSS, within 0:05:27.940000 --> 0:05:30.940000 the same SSID need to talk to each other? 0:05:30.940000 --> 0:05:35.220000 What if John and I need to do some file sharing, some peer-to-peer sharing, 0:05:35.220000 --> 0:05:38.360000 where both wireless connected to the same access point? 0:05:38.360000 --> 0:05:39.200000 Well, guess what? 0:05:39.200000 --> 0:05:43.080000 Now we have a situation where my traffic has to hit the access point, 0:05:43.080000 --> 0:05:47.280000 go all the way up that CAPWAP data tunnel to the controller, where it's 0:05:47.280000 --> 0:05:51.240000 processed and then shoved back into that tunnel all the way down so it 0:05:51.240000 --> 0:05:54.580000 can pop out the lightweight access point and John can see it. 0:05:54.580000 --> 0:05:57.460000 And now it's got to go all the way up and back again. 0:05:57.460000 --> 0:06:04.900000 So it's not a great option. 0:06:04.900000 --> 0:06:08.300000 Then they are closer to the controller itself. 0:06:08.300000 --> 0:06:13.140000 So it's definitely not a great option for client-to-client communications. 0:06:13.140000 --> 0:06:16.280000 What about when we have branch office laps? 0:06:16.280000 --> 0:06:18.520000 Branch office lightweight access points. 0:06:18.520000 --> 0:06:21.480000 Well, so we're talking now about a situation where an access point in 0:06:21.480000 --> 0:06:35.580000 a branch office might have to go across a slow-speed or even thousands 0:06:35.580000 --> 0:06:38.620000 of miles away from that lap. 0:06:38.620000 --> 0:06:40.820000 What happens if that tunnel goes down? 0:06:40.820000 --> 0:06:42.420000 What if we lose our internet connection? 0:06:42.420000 --> 0:06:44.240000 What if we lose our WAN connection? 0:06:44.240000 --> 0:06:48.080000 Well, a lightweight access point can't operate on its own. 0:06:48.080000 --> 0:06:49.960000 It needs a controller. 0:06:49.960000 --> 0:06:53.860000 So if that tunnel goes down, all those people in that branch, they just 0:06:53.860000 --> 0:06:55.320000 lost their connectivity. 0:06:55.320000 --> 0:06:58.280000 Because once that lap loses connectivity to its controller, it's going 0:06:58.280000 --> 0:07:02.340000 to disassociate and deauthenticate all the clients are connected to it 0:07:02.340000 --> 0:07:06.660000 because it can't handle them all by itself. 0:07:06.660000 --> 0:07:11.220000 So this could introduce long hairpins induced for branch office users 0:07:11.220000 --> 0:07:15.380000 that need to access resources that are actually there in the branch office 0:07:15.380000 --> 0:07:19.840000 themselves. And like I mentioned, if that cap-wap tunnel goes down, no 0:07:19.840000 --> 0:07:23.560000 Wi-Fi connectivity to anything for those branch office users. 0:07:23.560000 --> 0:07:28.100000 Now for that reason, Cisco developed something called FlexConnect. 0:07:28.100000 --> 0:07:30.840000 Now this used to go by previous names. 0:07:30.840000 --> 0:07:34.980000 It was originally called REAP and then hybrid REAP, which stood for remote 0:07:34.980000 --> 0:07:42.260000 -edge access point, remote-edge access point, and then hybrid remote-edge 0:07:42.260000 --> 0:07:45.280000 access point, and then it was called FlexConnect. 0:07:45.280000 --> 0:07:48.300000 But although it's gone through some iterations and some upgrades over 0:07:48.300000 --> 0:07:51.940000 time, the central premise of FlexConnect is the same. 0:07:51.940000 --> 0:07:57.960000 So this feature is a particular mode that's available on lightweight access 0:07:57.960000 --> 0:08:01.980000 points. And the controller has to support this. 0:08:01.980000 --> 0:08:06.620000 It's primarily designed for those remote -side or branch sites laps that 0:08:06.620000 --> 0:08:09.960000 are utilizing a controller that's located across a WAN connection, or 0:08:09.960000 --> 0:08:13.020000 across an internet connection located at the headquarters, and it's designed 0:08:13.020000 --> 0:08:17.020000 to alleviate those long hairpins. 0:08:17.020000 --> 0:08:20.820000 So wireless traffic destined for local resources can actually be switched 0:08:20.820000 --> 0:08:23.040000 locally by the lap. 0:08:23.040000 --> 0:08:28.240000 In other words, the data does not have to go across a data cap-wap tunnel. 0:08:28.240000 --> 0:08:33.660000 And now this bullet point right here really is only referring to if the 0:08:33.660000 --> 0:08:34.840000 tunnel goes down. 0:08:34.840000 --> 0:08:39.580000 In other words, if the lap loses its cap -wap control tunnel to the controller 0:08:39.580000 --> 0:08:41.880000 and says, Hey, I just lost my controller. 0:08:41.880000 --> 0:08:43.000000 What am I going to do? 0:08:43.000000 --> 0:08:46.860000 Well, if that access point is operating in FlexConnect mode, it can still 0:08:46.860000 --> 0:08:50.480000 hold on to the access to the clients it has, and it could potentially 0:08:50.480000 --> 0:08:54.140000 even authenticate new clients as they come on. 0:08:54.140000 --> 0:09:01.200000 So when a FlexConnect lap is configured, it will operate in one of two 0:09:01.200000 --> 0:09:05.020000 modes. Hopefully most of the time will be in what's called Connected mode, 0:09:05.020000 --> 0:09:08.360000 which means it is connected to the controller. 0:09:08.360000 --> 0:09:14.100000 It's got a cap-wap data and a cap-wap control tunnel back to that controller, 0:09:14.100000 --> 0:09:16.500000 or it could potentially operate in standalone mode. 0:09:16.500000 --> 0:09:19.640000 This is sort of more of a disaster recovery type of thing, which means, 0:09:19.640000 --> 0:09:22.060000 Hey, I've lost connectivity to the remote controller. 0:09:22.060000 --> 0:09:24.360000 I'm doing standalone mode. 0:09:24.360000 --> 0:09:31.720000 Now, let me go back here first of all to the second to the third and fourth 0:09:31.720000 --> 0:09:35.540000 bullet points. Give myself a little space right here. 0:09:35.540000 --> 0:09:42.880000 So if this is my branch, my branch office, and here's my lightweight access 0:09:42.880000 --> 0:09:48.160000 point right here, and we've got perhaps an internet connection. 0:09:48.160000 --> 0:09:51.420000 Let's draw that out. 0:09:51.420000 --> 0:09:55.780000 It's connected to the internet back to headquarters. 0:09:55.780000 --> 0:09:58.680000 And here is my controller. 0:09:58.680000 --> 0:10:04.520000 Right there. There's my controller. 0:10:04.520000 --> 0:10:09.840000 Now, we know that that lightweight access point is going to have to build 0:10:09.840000 --> 0:10:13.440000 two tunnels back to that controller. 0:10:13.440000 --> 0:10:19.980000 All right, what we call a control cap -wap tunnel, which is built across 0:10:19.980000 --> 0:10:23.600000 UDP, and the data. 0:10:23.600000 --> 0:10:29.860000 Cap-wap tunnel, which is also built across UDP, just a different port 0:10:29.860000 --> 0:10:36.280000 number. Now, if we have someone sitting right here and they're connected 0:10:36.280000 --> 0:10:42.300000 to the lightweight access point, a logical question would be, all right, 0:10:42.300000 --> 0:10:46.300000 how does the lightweight access point make the decision as far as when 0:10:46.300000 --> 0:10:51.060000 this person sends a Wi-Fi frame, whether that Wi-Fi frame should go across 0:10:51.060000 --> 0:10:55.780000 this data cap-wap tunnel to the controller and then be switched onto the 0:10:55.780000 --> 0:11:00.700000 wired LAN from here, or should the lightweight access point actually switch 0:11:00.700000 --> 0:11:05.060000 it itself onto a local LAN that is connected to? 0:11:05.060000 --> 0:11:09.540000 Initially, you might think, oh, that must be based on the IP address of 0:11:09.540000 --> 0:11:12.020000 where the data is going to. 0:11:12.020000 --> 0:11:15.720000 Well, the lightweight access point is not a router. 0:11:15.720000 --> 0:11:19.400000 It doesn't have the ability to look into the destination IP address of 0:11:19.400000 --> 0:11:22.160000 the packets that that client is sending. 0:11:22.160000 --> 0:11:23.080000 It can't do that. 0:11:23.080000 --> 0:11:25.880000 This is a layer one and layer two device. 0:11:25.880000 --> 0:11:30.200000 So the way that switching decision is made is not as dynamic as you might 0:11:30.200000 --> 0:11:36.540000 think. It's all based on what SSID that client is connected to. 0:11:36.540000 --> 0:11:40.360000 So on the controller, when the controller says, hey, access point, you 0:11:40.360000 --> 0:11:41.920000 can operate in flex-connect mode. 0:11:41.920000 --> 0:11:46.580000 The controller will be configured on the controller's GUI to push down 0:11:46.580000 --> 0:11:51.680000 at least a couple of SSIDs down to that lap. 0:11:51.680000 --> 0:11:55.380000 When you define those SSIDs on the controller, you will actually tell 0:11:55.380000 --> 0:12:00.220000 the controller, hey, this SSID right here, if someone associates to that 0:12:00.220000 --> 0:12:05.140000 on the lap, that means their data traffic is going to be switched on the 0:12:05.140000 --> 0:12:09.940000 lap itself. The lap itself will take their Wi-Fi frames, convert them 0:12:09.940000 --> 0:12:14.060000 into wired Ethernet frames, and dump them right out natively as Ethernet 0:12:14.060000 --> 0:12:16.120000 onto the wired LAN. 0:12:16.120000 --> 0:12:18.280000 So that SSID will be used. 0:12:18.280000 --> 0:12:21.320000 You connect to that when you want to connect to the branch office stuff 0:12:21.320000 --> 0:12:24.680000 like a printer at the branch office, or maybe a file server at the branch 0:12:24.680000 --> 0:12:28.900000 office. Then there will be another SSID that's created, and that one, 0:12:28.900000 --> 0:12:32.440000 the controller will say, hey, if somebody associates to that, they have 0:12:32.440000 --> 0:12:36.720000 to go across the CAPWAP data tunnel, all their data will go across that. 0:12:36.720000 --> 0:12:40.420000 So it's not based on the IP address of the actual packets from the client, 0:12:40.420000 --> 0:12:44.560000 it's based on whichever SSID they actually connect to. 0:12:44.560000 --> 0:12:50.480000 That's how the switching decision is made by FlexConnect. 0:12:50.480000 --> 0:12:56.820000 Now, so all of this has been talking about central centralized wireless 0:12:56.820000 --> 0:13:01.300000 architectures, and FlexConnect was a way to help alleviate some of those 0:13:01.300000 --> 0:13:05.460000 hairpins, depending on which SSID you're connected to. 0:13:05.460000 --> 0:13:11.500000 Another possibility, another type of wireless architecture is called converged 0:13:11.500000 --> 0:13:12.700000 wireless network architecture. 0:13:12.700000 --> 0:13:17.760000 And the idea here is, hey, instead of having our controller locate an 0:13:17.760000 --> 0:13:23.120000 essential spot like our data center, where there's long CAPWAP tunnels 0:13:23.120000 --> 0:13:26.700000 that have to be built to reach that guy, why don't we do this? 0:13:26.700000 --> 0:13:30.420000 Why don't we take that functionality of the controller and move it down 0:13:30.420000 --> 0:13:33.860000 to like the distribution or the access layer? 0:13:33.860000 --> 0:13:38.720000 As a matter of fact, why don't we take the switch, the layer, the land 0:13:38.720000 --> 0:13:41.940000 switch to that access point is physically connected to on his ethernet 0:13:41.940000 --> 0:13:46.380000 port, and why don't we put the controller functionality right there in 0:13:46.380000 --> 0:13:50.300000 the switch? Now, there's still going to be two CAPWAP tunnels built, a 0:13:50.300000 --> 0:13:53.320000 data tunnel and a control tunnel, but now they're going to be really, 0:13:53.320000 --> 0:13:57.080000 really short, because they're only going from the access point, maybe 0:13:57.080000 --> 0:14:02.980000 5, 10, 20 feet to the switch it's connected to on the other side. 0:14:02.980000 --> 0:14:06.760000 This is called a converged wireless network architecture, where we're 0:14:06.760000 --> 0:14:10.900000 basically implementing multiple controllers to divide the load from the 0:14:10.900000 --> 0:14:17.100000 access points. Now, historically, this used to be done by actually taking 0:14:17.100000 --> 0:14:22.320000 Wi-Fi controller modules, physical modules you can hold, and sliding them 0:14:22.320000 --> 0:14:25.480000 into an available slot in a switch's chassis. 0:14:25.480000 --> 0:14:29.120000 So you had to have a switch that was a module or a switch like a 6500 0:14:29.120000 --> 0:14:33.860000 or a 6800 or something, by one of these special controller modules, slide 0:14:33.860000 --> 0:14:37.580000 it there into the chassis, and that was called converged wireless, because 0:14:37.580000 --> 0:14:41.280000 now the switch was doing switching, and it had the special module that 0:14:41.280000 --> 0:14:44.800000 could act as a wireless LAN controller as well. 0:14:44.800000 --> 0:14:48.460000 Cisco is sort of moving away from that now, and now what they're doing 0:14:48.460000 --> 0:14:51.840000 is they're saying, hey, if you buy the special Cisco switch called the 0:14:51.840000 --> 0:14:55.460000 Cisco Catalyst 9300, and I'm sure they're going to create some more in 0:14:55.460000 --> 0:15:01.480000 the future as well, well, this 9300 is running iOS XE software, the latest 0:15:01.480000 --> 0:15:05.700000 and greatest software for programmability and network automations, got 0:15:05.700000 --> 0:15:10.220000 all sorts of APIs and stuff built into it, and hey, guess what one of 0:15:10.220000 --> 0:15:12.900000 the features is that iOS XE gives you? 0:15:12.900000 --> 0:15:17.800000 If you have it in a 9300 switch, you now also have the ability to turn 0:15:17.800000 --> 0:15:22.260000 on wireless LAN controller functionality right there within the switch 0:15:22.260000 --> 0:15:28.820000 itself. So the idea here is very simple, that your lap, your light weight 0:15:28.820000 --> 0:15:32.560000 access point would be physically connected to that switch, and in that 0:15:32.560000 --> 0:15:36.140000 exact same switch, it's running the controller functionality. 0:15:36.140000 --> 0:15:39.300000 So here you can see the CAPWAP data and control tunnels now are very, 0:15:39.300000 --> 0:15:45.060000 very short. We don't even really have to worry about latency at this point. 0:15:45.060000 --> 0:15:49.620000 So there's some many benefits and some drawbacks with the converged network 0:15:49.620000 --> 0:15:51.260000 architecture as well. 0:15:51.260000 --> 0:15:54.640000 So the benefits are you've got a very short CAPWAP data tunnel. 0:15:54.640000 --> 0:15:58.320000 This reduces the impact of hairpins, we don't have to worry about really 0:15:58.320000 --> 0:16:00.980000 long round trip transmit times. 0:16:00.980000 --> 0:16:06.160000 This is also better support for faster Wi-Fi technologies. 0:16:06.160000 --> 0:16:10.900000 You see, up until the last few years, your Wi-Fi clients, when they connected 0:16:10.900000 --> 0:16:14.600000 to the access point, the actual speeds at which they transmitted those 0:16:14.600000 --> 0:16:17.560000 clients was under 1 gigabit. 0:16:17.560000 --> 0:16:20.400000 Typically speaking, it was like in the hundreds, if you were talking about 0:16:20.400000 --> 0:16:25.340000 802.11N, you were lucky to get like 300 megabits per second. 0:16:25.340000 --> 0:16:26.700000 Lucky to get that. 0:16:26.700000 --> 0:16:33.100000 Well, with some of the later Wi-Fi developments like 802.11AC phase 2, 0:16:33.100000 --> 0:16:39.080000 802.11AD and the up and coming 802 .11AX, now we have a situation where 0:16:39.080000 --> 0:16:43.520000 a Wi-Fi client, if it's correctly positioned and really close to the access 0:16:43.520000 --> 0:16:48.100000 point, if the stars and the moon align just perfectly, that Wi-Fi client 0:16:48.100000 --> 0:16:51.960000 could actually be transmitting at faster than gigabit speeds. 0:16:51.960000 --> 0:16:55.620000 It could be transmitted at 1.5 gigs, two gigs, or maybe even faster than 0:16:55.620000 --> 0:17:01.120000 that. Well, most access points, if you're going to transmit it that fast, 0:17:01.120000 --> 0:17:05.660000 first of all, number one, most access points have a 10, 100, 1,000 connection 0:17:05.660000 --> 0:17:07.000000 on the back of them. 0:17:07.000000 --> 0:17:10.400000 How's that access point going to handle incoming traffic from the Wi-Fi 0:17:10.400000 --> 0:17:14.820000 client? It's coming in at like 1.5 gigabits, when the maximum it can transmit 0:17:14.820000 --> 0:17:18.320000 on the outside to the switch, is 1 gigabit. 0:17:18.320000 --> 0:17:19.860000 Well, here's a good thing. 0:17:19.860000 --> 0:17:22.680000 First of all, you wouldn't buy an access point that only has one interface 0:17:22.680000 --> 0:17:25.180000 like that. You'd be setting yourself up for failure. 0:17:25.180000 --> 0:17:30.380000 So you'd buy a higher end access point that has two of those 10, 100, 0:17:30.380000 --> 0:17:34.480000 1,000 interfaces, and then you could bundle them together into a link 0:17:34.480000 --> 0:17:35.860000 aggregation group. 0:17:35.860000 --> 0:17:38.520000 We're not going to talk about that, but if you're familiar with switching, 0:17:38.520000 --> 0:17:41.980000 basically the same thing is ether channeling. 0:17:41.980000 --> 0:17:45.560000 Now you've got your bandwidth that can handle those really fast Wi-Fi 0:17:45.560000 --> 0:17:47.180000 clients. Let's say you've done that. 0:17:47.180000 --> 0:17:48.700000 You already finished with that. 0:17:48.700000 --> 0:17:49.960000 But now think about this. 0:17:49.960000 --> 0:17:54.820000 Those clients are transmitting at 1.5 gigabits or faster. 0:17:54.820000 --> 0:17:57.740000 Through a capwap data tunnel. 0:17:57.740000 --> 0:18:01.020000 What if that data tunnel terminates on a central wireless controller that's 0:18:01.020000 --> 0:18:03.580000 like six router hops away? 0:18:03.580000 --> 0:18:07.660000 Now we might have a problem with getting that 1.5 or two or three gigabits 0:18:07.660000 --> 0:18:12.840000 of traffic up to that controller and not delaying it, not dropping it. 0:18:12.840000 --> 0:18:15.760000 Well, with converged wireless, we don't have to worry about that because 0:18:15.760000 --> 0:18:20.280000 the tunnel ends right there at the connected switch that the access point 0:18:20.280000 --> 0:18:25.440000 is connected to. 0:18:25.440000 --> 0:18:29.440000 Also, we have less access points per embedded controller. 0:18:29.440000 --> 0:18:32.740000 Sometimes we call these embedded controllers because the controller functionality 0:18:32.740000 --> 0:18:37.100000 is embedded right into the local switch itself. 0:18:37.100000 --> 0:18:41.660000 So what we're talking about here is in a centralized wireless architecture, 0:18:41.660000 --> 0:18:46.200000 a controller might actually be controlling potentially thousands of access 0:18:46.200000 --> 0:18:48.960000 points, just depending on how big the situation is. 0:18:48.960000 --> 0:18:53.220000 Here, in a converged wireless architecture, where it's built into the 0:18:53.220000 --> 0:18:57.100000 switch, that switch is only going to be controlling access points are 0:18:57.100000 --> 0:19:00.700000 probably physically connected on its switch ports. 0:19:00.700000 --> 0:19:04.940000 So we might be talking about maybe a few dozen access points at the absolute 0:19:04.940000 --> 0:19:10.120000 most. So it's a lot less taxing for the controller to do that. 0:19:10.120000 --> 0:19:14.500000 And now we can have controller functionality right there at the branch 0:19:14.500000 --> 0:19:18.560000 site. Now, there are just a couple, just really sort of one big drawback 0:19:18.560000 --> 0:19:20.960000 to this, which is dollars. 0:19:20.960000 --> 0:19:25.300000 Okay? So if you're dealing with converged wireless architecture where 0:19:25.300000 --> 0:19:28.520000 you're actually buying some of the older modules, the physical controllers 0:19:28.520000 --> 0:19:32.780000 that slip into a switch, well, you got to buy those things. 0:19:32.780000 --> 0:19:34.360000 Those things aren't free. 0:19:34.360000 --> 0:19:35.840000 They're kind of pricey. 0:19:35.840000 --> 0:19:39.080000 And so if you think about this now, now you think about, okay, all of 0:19:39.080000 --> 0:19:43.020000 our access layer switches have to have these modules put into them. 0:19:43.020000 --> 0:19:46.980000 To support the access points are physically connected to those switches. 0:19:46.980000 --> 0:19:50.620000 That's a little bit more pricey than buying just one controller appliance 0:19:50.620000 --> 0:19:53.340000 which is sitting up in the data center somewhere. 0:19:53.340000 --> 0:19:57.580000 Or you say, well, hey, I'm getting the 9300 series switch, so I don't 0:19:57.580000 --> 0:19:59.220000 have to buy a separate controller. 0:19:59.220000 --> 0:20:04.440000 Okay, great. But that 9300 series switch is not the cheapest switch that 0:20:04.440000 --> 0:20:07.440000 Cisco sells. It's actually a fairly pricey switch. 0:20:07.440000 --> 0:20:10.380000 It's on the higher end as far as dollar amounts are concerned. 0:20:10.380000 --> 0:20:14.440000 So either way, if you want to go with a converged network architecture 0:20:14.440000 --> 0:20:18.580000 for wireless, it's going to cost you a little bit more money to do this. 0:20:18.580000 --> 0:20:21.580000 But as you can see, there are some great benefits to this. 0:20:21.580000 --> 0:20:24.840000 So that concludes this video. 0:20:24.840000 --> 0:20:25.720000 Thank you for watching.