WEBVTT 0:00:03.160000 --> 0:00:07.800000 Hello and welcome to this video titled Infrastructure Connections of Wireless 0:00:07.800000 --> 0:00:09.840000 Land Components. 0:00:09.840000 --> 0:00:13.580000 In this video I'm going to cover Wireless Land Infrastructure Connections. 0:00:13.580000 --> 0:00:17.040000 We're going to take a look at the connections on access points and the 0:00:17.040000 --> 0:00:21.340000 connections on controllers in order to connect them to the wired infrastructure. 0:00:21.340000 --> 0:00:24.080000 And I'm also going to talk about something called lag and how that is 0:00:24.080000 --> 0:00:28.380000 used in this situation as well as a benefit. 0:00:28.380000 --> 0:00:33.340000 So, as a review, the components, the basic components of any wireless 0:00:33.340000 --> 0:00:37.720000 land consist of number one and access point and that access point could 0:00:37.720000 --> 0:00:40.760000 be operating in autonomous or lightweight mode. 0:00:40.760000 --> 0:00:44.920000 Certainly, we need some wireless nicks on the host devices. 0:00:44.920000 --> 0:00:49.080000 We also need some wireless transceivers and antennas built into those 0:00:49.080000 --> 0:00:50.840000 WiFi hosts and access points. 0:00:50.840000 --> 0:00:55.200000 Now, that right there is the absolute minimum mandatory stuff we need 0:00:55.200000 --> 0:00:56.780000 for a wireless land. 0:00:56.780000 --> 0:01:00.340000 Now, when we talk about multiple wireless lands, for example, in an enterprise 0:01:00.340000 --> 0:01:03.800000 or campus, we're probably going to have a controller, at least one controller 0:01:03.800000 --> 0:01:07.860000 in there, to control and manage all those access points as well. 0:01:07.860000 --> 0:01:13.880000 So, that's on the WiFi side, but all the controller and the access points 0:01:13.880000 --> 0:01:18.740000 still need physical connections to connect to the physical distribution 0:01:18.740000 --> 0:01:22.280000 system. Once again, the distribution system, in case you're not familiar 0:01:22.280000 --> 0:01:24.700000 with that term, means the wired network. 0:01:24.700000 --> 0:01:30.060000 From the IEEE 802.11 perspective, the wired network is not called the 0:01:30.060000 --> 0:01:34.480000 wired network. They call it the distribution system. 0:01:34.480000 --> 0:01:37.140000 So, what do these connections look like? 0:01:37.140000 --> 0:01:41.920000 What physically would we get when we get an access point or a controller? 0:01:41.920000 --> 0:01:45.620000 Well, on the access point itself, you're going to have one or possibly 0:01:45.620000 --> 0:01:50.280000 two 10, 100, 100, 1000 ports. 0:01:50.280000 --> 0:01:54.580000 Clearly the switch that's connected to that access point is going to have 0:01:54.580000 --> 0:01:57.400000 to have some physical interfaces as well. 0:01:57.400000 --> 0:02:01.180000 And typically speaking, from the switch directly connected to the access 0:02:01.180000 --> 0:02:04.380000 point, you would configure that as a trunk connection. 0:02:04.380000 --> 0:02:08.440000 Because that access point, most likely, is going to have multiple SSIDs 0:02:08.440000 --> 0:02:10.520000 inside of it that is advertising. 0:02:10.520000 --> 0:02:14.700000 Each of those SSIDs is going to be associated to a unique VLAN and it's 0:02:14.700000 --> 0:02:19.660000 going to be tagging those VLANs in 802.1Q tags to the switch. 0:02:19.660000 --> 0:02:23.260000 So the switch has to support trunking in order to recognize those 802 0:02:23.260000 --> 0:02:27.460000 .1Q tags. Then of course, on the controller side, we're going to have some 0:02:27.460000 --> 0:02:32.180000 physical interfaces on it as well in order to connect to the switch. 0:02:32.180000 --> 0:02:34.780000 So let's dive a little bit deeper into what these connections look like, 0:02:34.780000 --> 0:02:38.040000 starting with the access point. 0:02:38.040000 --> 0:02:40.780000 So here on the access point, just like on pretty much any other network 0:02:40.780000 --> 0:02:43.100000 device, you're going to have a console port. 0:02:43.100000 --> 0:02:45.720000 This console port is what you're going to connect to from your laptop 0:02:45.720000 --> 0:02:48.060000 in order to manage this device. 0:02:48.060000 --> 0:02:51.660000 This will give you access, for example, to the command line of the access 0:02:51.660000 --> 0:02:56.260000 point itself. Now with a lightweight access point, typically speaking, 0:02:56.260000 --> 0:02:59.720000 there's very little you should really need to do on the command line, 0:02:59.720000 --> 0:03:02.660000 but sometimes you do need to get into that to turn on certain features 0:03:02.660000 --> 0:03:06.080000 or in order to troubleshooting of the access point. 0:03:06.080000 --> 0:03:11.200000 You will also have a data port, an ethernet port, which is most likely 0:03:11.200000 --> 0:03:14.360000 going to have a power over ethernet. 0:03:14.360000 --> 0:03:17.940000 So in the event that you don't have a power brick or some other AC adapter 0:03:17.940000 --> 0:03:21.440000 to plug into the access point, you can always power it with power over 0:03:21.440000 --> 0:03:23.420000 ethernet from the connected switch. 0:03:23.420000 --> 0:03:26.820000 Now that will be your primary data port right there. 0:03:26.820000 --> 0:03:31.560000 However, what if we have a Wi-Fi client that's operating at a super fast 0:03:31.560000 --> 0:03:35.600000 speed like 802.11AC phase two or higher? 0:03:35.600000 --> 0:03:41.280000 In that particular case, that client wants to transmit at multi gigabit 0:03:41.280000 --> 0:03:47.820000 speeds and a single 10, 100, 1000 interface won't cut it to take that 0:03:47.820000 --> 0:03:50.660000 data and put it onto the wired distribution system. 0:03:50.660000 --> 0:03:54.800000 So in that case, your access port, your access point would have another 0:03:54.800000 --> 0:03:58.880000 10, 100, 1000 interface called an aux port. 0:03:58.880000 --> 0:04:02.520000 We could bundle those together into a link aggregation group and that 0:04:02.520000 --> 0:04:06.600000 would support multi-gigabit speeds from that client. 0:04:06.600000 --> 0:04:09.280000 We'll talk more about lag here in just a moment. 0:04:09.280000 --> 0:04:11.960000 Now let's move over to the controller side. 0:04:11.960000 --> 0:04:15.320000 Here's a picture of a controller. 0:04:15.320000 --> 0:04:18.300000 So the controller's interfaces also are going to be divided into several 0:04:18.300000 --> 0:04:19.480000 different categories. 0:04:19.480000 --> 0:04:22.540000 It also will have a console port. 0:04:22.540000 --> 0:04:27.040000 So you can connect your laptop directly to that to access directly the 0:04:27.040000 --> 0:04:31.440000 command line of that controller. 0:04:31.440000 --> 0:04:35.800000 Now, if you want to connect to the, if you want to send IP packets to 0:04:35.800000 --> 0:04:38.960000 that controller, in other words, if I want to tell net or SSH to that 0:04:38.960000 --> 0:04:44.440000 controller, or if I want to access its web based GUI over HTTPS or HTTP, 0:04:44.440000 --> 0:04:48.820000 then I would connect my laptop to its service port. 0:04:48.820000 --> 0:04:53.740000 So the service port actually accepts IP, accepts incoming IP connections. 0:04:53.740000 --> 0:04:55.800000 This is also called a management port. 0:04:55.800000 --> 0:05:00.700000 But notice this is only meant for connecting on the same subnet. 0:05:00.700000 --> 0:05:03.960000 In other words, the service port does not have routing capability. 0:05:03.960000 --> 0:05:07.460000 By default, it doesn't have a default gateway or anything like that. 0:05:07.460000 --> 0:05:11.760000 So the laptop you're using to connect to that so you can SSH or tell net 0:05:11.760000 --> 0:05:16.280000 or get to the GUI would have to be on the exact same subnet as whatever 0:05:16.280000 --> 0:05:19.600000 the subnet is configured on the service port itself. 0:05:19.600000 --> 0:05:22.420000 You might also have a redundancy port. 0:05:22.420000 --> 0:05:29.180000 This is used to connect two Cisco Calist 9800s directly to each other 0:05:29.180000 --> 0:05:34.360000 for stateful switch over and high availability. 0:05:34.360000 --> 0:05:38.460000 In this particular situation, one of the controllers would be active, 0:05:38.460000 --> 0:05:41.220000 the other would be redundant or in a standby state. 0:05:41.220000 --> 0:05:44.580000 And the active controller would actually download everything it knows. 0:05:44.580000 --> 0:05:48.640000 Its configuration, all the wireless clients it knows about, everything 0:05:48.640000 --> 0:05:53.440000 would be downloaded and replicated to the standby or redundant controller. 0:05:53.440000 --> 0:05:57.080000 So if the active controller fails, the redundant controller could come 0:05:57.080000 --> 0:06:00.580000 up and we wouldn't have any loss of connectivity for clients. 0:06:00.580000 --> 0:06:04.460000 So that all takes place across a redundancy port. 0:06:04.460000 --> 0:06:07.320000 And then of course you also have your data ports as well. 0:06:07.320000 --> 0:06:11.500000 These connect to the distribution system, they connect to the wired network. 0:06:11.500000 --> 0:06:18.100000 Now we have to talk about lag. 0:06:18.100000 --> 0:06:21.940000 Lag is the idea of taking your distribution ports, your physical data 0:06:21.940000 --> 0:06:26.940000 ports and bundling them together into a single logical port group. 0:06:26.940000 --> 0:06:30.920000 This is almost identical to the concept of ether channel on switches. 0:06:30.920000 --> 0:06:34.300000 As a matter of fact, on the switch side, it would be considered, it would 0:06:34.300000 --> 0:06:37.000000 be configured for ether channel. 0:06:37.000000 --> 0:06:40.200000 So the same way that you know to configure a switch for ether channel. 0:06:40.200000 --> 0:06:43.820000 So on the switch side here, for those interfaces there, you would say 0:06:43.820000 --> 0:06:49.960000 interface, range and whatever your gigabit interfaces are, gig 1 slash 0:06:49.960000 --> 0:06:56.740000 0 slash 1 through 1 slash 0 slash 4 or whatever it happens to be. 0:06:56.740000 --> 0:06:59.100000 And then you would make those switch ports. 0:06:59.100000 --> 0:07:09.040000 You'd want to say switch port mode trunk because you want to do trunking 0:07:09.040000 --> 0:07:12.020000 with that controller because everything leaving that controller is going 0:07:12.020000 --> 0:07:14.980000 to have a tag for the VLAN that the traffic belongs to. 0:07:14.980000 --> 0:07:17.300000 And then you put in a channel group. 0:07:17.300000 --> 0:07:23.000000 Channel dash group one mode. 0:07:23.000000 --> 0:07:28.680000 Now Cisco switches when it comes to ether channeling, they support PAGP, 0:07:28.680000 --> 0:07:30.700000 which is Cisco proprietary. 0:07:30.700000 --> 0:07:32.620000 Well, the controller doesn't support that. 0:07:32.620000 --> 0:07:34.420000 So you can't do PAGP. 0:07:34.420000 --> 0:07:39.720000 They also support LACP. 0:07:39.720000 --> 0:07:40.560000 Well guess what? 0:07:40.560000 --> 0:07:42.220000 The controller doesn't support that either. 0:07:42.220000 --> 0:07:47.320000 Can't do LACP. So when you're talking about lag between a controller and 0:07:47.320000 --> 0:07:51.100000 a switch, the channel group mode has to be on. 0:07:51.100000 --> 0:07:54.300000 That's the only supported mode that the controller will represent or I 0:07:54.300000 --> 0:07:57.000000 should say understand. 0:07:57.000000 --> 0:08:02.460000 Now you can also implement this on access points. 0:08:02.460000 --> 0:08:05.700000 Those ethernet ports on the back of the access point that we just looked 0:08:05.700000 --> 0:08:09.280000 at, you could also use lag for that as well. 0:08:09.280000 --> 0:08:14.100000 And in this case, the access points, funny enough, actually do support 0:08:14.100000 --> 0:08:19.200000 LACP. So if you're familiar with LACP and active and passive and all that, 0:08:19.200000 --> 0:08:23.360000 you can configure the switch ports for LACP and bundle those into an ether 0:08:23.360000 --> 0:08:25.120000 channel going to the access point. 0:08:25.120000 --> 0:08:29.760000 But the controller, the controller lag does not support LACP. 0:08:29.760000 --> 0:08:35.100000 So this gives you redundancy and load balancing. 0:08:35.100000 --> 0:08:38.100000 Now, as far as the load balancing is concerned, one of the little gotcha 0:08:38.100000 --> 0:08:41.480000 here, one of the thing to be aware of is what you see right here. 0:08:41.480000 --> 0:08:45.400000 So the connected switch ports, the load balancing has to be using layer 0:08:45.400000 --> 0:08:49.160000 four source and destination ports. 0:08:49.160000 --> 0:08:52.920000 Most switches by default when you configure an ether channel, the way 0:08:52.920000 --> 0:08:57.400000 they do their load balancing is based on source Mac. 0:08:57.400000 --> 0:09:00.540000 That's typically the default in the vast majority of switches I've ever 0:09:00.540000 --> 0:09:03.040000 seen. That's not going to work here. 0:09:03.040000 --> 0:09:07.680000 So traffic is coming off the distribution system and going into the controller 0:09:07.680000 --> 0:09:10.640000 or going down into the access point. 0:09:10.640000 --> 0:09:14.560000 If you want that to be load balanced across the lag, you want to change 0:09:14.560000 --> 0:09:19.760000 that to use the layer four source and destination port numbers. 0:09:19.760000 --> 0:09:29.880000 Just a little bit more about link aggregation groups. 0:09:29.880000 --> 0:09:38.300000 So as far as the access point is concerned, this only works when the access 0:09:38.300000 --> 0:09:40.640000 point is in local mode. 0:09:40.640000 --> 0:09:45.680000 Recall that local mode is the opposite of an autonomous access point. 0:09:45.680000 --> 0:09:51.120000 Local mode means that this access point is being controlled by a controller. 0:09:51.120000 --> 0:09:55.300000 So that's the only time that access point can bundle its ethernet uplinks 0:09:55.300000 --> 0:09:58.880000 into a link aggregation group. 0:09:58.880000 --> 0:10:01.340000 Also this is a Cisco feature. 0:10:01.340000 --> 0:10:05.360000 This is not tested between Cisco access points and non-Cisco controllers 0:10:05.360000 --> 0:10:08.220000 or non-Cisco switches I should say. 0:10:08.220000 --> 0:10:12.020000 So if you try doing that, you're on your own. 0:10:12.020000 --> 0:10:16.580000 And the wireless LAN controller and the access point has to be enabled 0:10:16.580000 --> 0:10:20.720000 for this. So on the wireless LAN controller, we have to go in and tell 0:10:20.720000 --> 0:10:24.440000 it this is a feature that we're going to turn on and that we're going 0:10:24.440000 --> 0:10:26.120000 to enable for the access points. 0:10:26.120000 --> 0:10:29.120000 And then we actually have to go to the access points themselves, get into 0:10:29.120000 --> 0:10:30.280000 their command line. 0:10:30.280000 --> 0:10:33.300000 This is one of the very rare times you need to get into the command line 0:10:33.300000 --> 0:10:37.340000 of a lightweight access point and enable this feature in the access point 0:10:37.340000 --> 0:10:44.360000 itself. And like I mentioned, access points do support the LACP or on 0:10:44.360000 --> 0:10:47.100000 modes. They don't support PAGP. 0:10:47.100000 --> 0:10:51.800000 And this is what you're going to want to do if your clients, if your Wi 0:10:51.800000 --> 0:10:55.100000 -Fi clients, your tablets, laptops, smartphones are doing the really fast 0:10:55.100000 --> 0:11:03.600000 Wi-Fi of like 802.11ac phase 2, 802 .11ad or the up and coming 802.11ax, 0:11:03.600000 --> 0:11:07.200000 you're going to need to get an access point with two or more of those 0:11:07.200000 --> 0:11:11.600000 10, 100, 1000 links and bundle them together into lag. 0:11:11.600000 --> 0:11:16.080000 That's just a few final considerations about link aggregation groups. 0:11:16.080000 --> 0:11:20.980000 Controllers, like I mentioned, they don't support LACP or PAGP. 0:11:20.980000 --> 0:11:24.920000 As far as the load balancing of frames is concerned, when the frames are 0:11:24.920000 --> 0:11:30.360000 leaving the access point and going into the switch, or the frames are 0:11:30.360000 --> 0:11:35.440000 leaving the controller and going into its connected switch, that load 0:11:35.440000 --> 0:11:39.880000 balancing is done on a proprietary basis by the controller or the access 0:11:39.880000 --> 0:11:42.380000 point. You don't have any control over that. 0:11:42.380000 --> 0:11:49.020000 Only one AP Manager interface is allowed when ports are bundled into a 0:11:49.020000 --> 0:11:52.780000 lag. What the heck is an AP Manager interface? 0:11:52.780000 --> 0:11:54.800000 Okay, let's go back for a second. 0:11:54.800000 --> 0:11:58.380000 We know that a lightweight access point is going to build a series of 0:11:58.380000 --> 0:12:01.900000 two CAPWAP tunnels to the controller. 0:12:01.900000 --> 0:12:06.740000 It's going to build a CAPWAP control tunnel and a CAPWAP data tunnel. 0:12:06.740000 --> 0:12:11.640000 We know those tunnels, the source IP address is the access point. 0:12:11.640000 --> 0:12:14.080000 What's the destination IP address? 0:12:14.080000 --> 0:12:16.460000 The destination IP address is on the controller. 0:12:16.460000 --> 0:12:18.440000 Well, where on the controller is it? 0:12:18.440000 --> 0:12:24.380000 It's on a logical interface called an AP Manager interface. 0:12:24.380000 --> 0:12:25.960000 Think about like this. 0:12:25.960000 --> 0:12:29.520000 If you're familiar with Cisco switches, you know that Cisco switches have 0:12:29.520000 --> 0:12:32.860000 physical ports that you plug your cables into. 0:12:32.860000 --> 0:12:36.560000 They also have logical interfaces like a switched virtual interface. 0:12:36.560000 --> 0:12:40.920000 When you go into a switch and you type interface VLAN 1 or interface VLAN 0:12:40.920000 --> 0:12:44.240000 5, that's not a physical thing you can see and touch and feel. 0:12:44.240000 --> 0:12:47.840000 It's a logical interface that you create and then you can put an IP address 0:12:47.840000 --> 0:12:53.420000 on it. In a similar fashion, the AP Manager interface is a logical interface 0:12:53.420000 --> 0:12:55.680000 on a controller. 0:12:55.680000 --> 0:13:00.920000 Now, if that controller has got four or eight physical data ports that 0:13:00.920000 --> 0:13:04.960000 are connected to a physical switch, if those data ports are separate, 0:13:04.960000 --> 0:13:09.580000 they're not in a lag, they're standalone data ports, then typically speaking, 0:13:09.580000 --> 0:13:14.640000 you would have an AP Manager interface associated with each one of those 0:13:14.640000 --> 0:13:18.900000 data ports. So some of your access points might be building a couple of 0:13:18.900000 --> 0:13:23.360000 CapWap tunnels to the AP Manager interface, the IP address on that interface 0:13:23.360000 --> 0:13:25.980000 that's on physical port number one. 0:13:25.980000 --> 0:13:30.320000 Other groups of access points would be building their sets of CapWap tunnels 0:13:30.320000 --> 0:13:35.940000 to another IP address on that controller that's on AP Manager interface 0:13:35.940000 --> 0:13:40.300000 number two. And that's associated with physical port number two. 0:13:40.300000 --> 0:13:42.880000 Well, what this is saying here is that when those physical interfaces 0:13:42.880000 --> 0:13:48.280000 are bundled into a link aggregation group, now we just need one IP address 0:13:48.280000 --> 0:13:50.900000 on one AP Manager. 0:13:50.900000 --> 0:13:54.020000 And all of the access points will form their CapWap tunnels to that one 0:13:54.020000 --> 0:13:58.420000 IP address. And now if any of those physical interfaces go down, it's 0:13:58.420000 --> 0:14:02.560000 not going to affect the access points because they can still reach that 0:14:02.560000 --> 0:14:06.800000 one IP address that they form their CapWap tunnels too. 0:14:06.800000 --> 0:14:11.160000 If you didn't have lag and say for example, port number one went down 0:14:11.160000 --> 0:14:14.880000 the physical port, well, whatever AP Manager interface was associated 0:14:14.880000 --> 0:14:18.140000 to that physical port would now be unreachable. 0:14:18.140000 --> 0:14:21.940000 And all the access points that had associated and built their CapWap tunnels 0:14:21.940000 --> 0:14:25.040000 to that IP address would now be stuck. 0:14:25.040000 --> 0:14:29.480000 They'd have to disconnect their clients and find another IP address that 0:14:29.480000 --> 0:14:32.700000 they could build new CapWap tunnels too. 0:14:32.700000 --> 0:14:36.320000 So that concludes this video. 0:14:36.320000 --> 0:14:37.100000 Thank you for watching.