WEBVTT

1
00:00.000 --> 00:04.590
When a lightweight access point comes online, it forms a tunnel to the wireless

2
00:04.590 --> 00:05.460
lane controller.

3
00:05.460 --> 00:10.830
This tunnel is known as the control and provisioning of wireless access points

4
00:10.830 --> 00:12.640
or capwap.

5
00:12.640 --> 00:18.040
Capwap is a very important part of a wireless controller architecture,

6
00:18.040 --> 00:23.150
because what we have is not just a wireless lane controller communicating

7
00:23.150 --> 00:29.640
through the network to an access point.

8
00:29.640 --> 00:36.010
Instead, what we have is we have a tunnel that is built, then we send our
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

8
00:29.640 --> 00:36.010
Instead, what we have is we have a tunnel that is built, then we send our

9
00:36.010 --> 00:39.080
management traffic into this tunnel.

10
00:39.080 --> 00:41.720
But it's not just the management traffic.

11
00:41.720 --> 00:47.680
We also send our wireless client or station traffic in here as well.

12
00:47.680 --> 00:51.200
So it's our management traffic and our data traffic.

13
00:51.200 --> 00:55.690
And so both of these types of traffic will traverse the tunnel through the

14
00:55.690 --> 00:58.920
network to get to the wireless lane controller.

15
00:58.920 --> 01:03.960
Now we might need a quick refresher on what exactly a tunnel architecture is.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

15
00:58.920 --> 01:03.960
Now we might need a quick refresher on what exactly a tunnel architecture is.

16
01:03.960 --> 01:08.680
If we think back to the VXLAN tunnels for our fabric types of architecture, it

17
01:08.680 --> 01:10.680
's going to be a very similar concept.

18
01:10.680 --> 01:16.840
The idea is I take an original packet and I encapsulate it further.

19
01:16.840 --> 01:21.700
Normally I'm encapsulating it at layer 3 and layer 2, but then I throw another

20
01:21.700 --> 01:23.320
header in front of this.

21
01:23.320 --> 01:27.960
And this additional tunnel header is going to be what the network is paying

22
01:27.960 --> 01:29.080
attention to.

23
01:29.080 --> 01:33.080
The network doesn't see inside of this packet.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

23
01:29.080 --> 01:33.080
The network doesn't see inside of this packet.

24
01:33.080 --> 01:38.920
So this external tunnel header is saying, "Hey, you know what I'm destined for?

25
01:38.920 --> 01:42.440
The wireless client might be destined out to the internet."

26
01:42.440 --> 01:47.720
But this tunnel destination is the wireless lane controller IP address.

27
01:47.720 --> 01:53.880
And the source is not the client, the source is the access point IP address.

28
01:53.880 --> 01:59.600
So the underlay, this local area network, whatever this is, a bunch of switches

29
01:59.600 --> 02:01.080
and routers potentially,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

29
01:59.600 --> 02:01.080
and routers potentially,

30
02:01.080 --> 02:04.840
it's going to look at this destination and source IP address.

31
02:04.840 --> 02:08.690
It has no idea what the client source is as no idea what the internet

32
02:08.690 --> 02:09.880
destination is.

33
02:09.880 --> 02:15.080
Those are inside of the inner packet and those aren't seen.

34
02:15.080 --> 02:20.280
Once the wireless lane controller receives this packet, it's going to strip off

35
02:20.280 --> 02:23.080
the tunnel header,

36
02:23.080 --> 02:29.160
look at the original packet and it's going to send it on to the network,

37
02:29.160 --> 02:34.440
which funny enough usually involves sending it right back out one of the links
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

37
02:29.160 --> 02:34.440
which funny enough usually involves sending it right back out one of the links

38
02:34.440 --> 02:35.880
that it brought it in on.

39
02:35.880 --> 02:39.160
But in this case, it doesn't have a tunnel header anymore.

40
02:39.160 --> 02:44.320
So the local area network can look at the actual destination and forward it on

41
02:44.320 --> 02:46.440
to wherever it's supposed to be going.

42
02:46.440 --> 02:55.240
So this creates a lot of interesting conversations around our client traffic.

43
02:55.240 --> 02:59.890
And this brings us back to what we said is important, which is the wireless

44
02:59.890 --> 03:01.480
lane controller location.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

44
02:59.890 --> 03:01.480
lane controller location.

45
03:01.480 --> 03:06.850
The reason why the location matters so much, and there's actually quite a few

46
03:06.850 --> 03:07.240
reasons.

47
03:07.240 --> 03:11.830
But one of the main reasons is because the location of the wireless lane

48
03:11.830 --> 03:12.520
controller

49
03:12.520 --> 03:17.160
is where our wireless subnets are going to live,

50
03:17.160 --> 03:23.880
which might seem logical at first that wireless subnets should live where the

51
03:23.880 --> 03:25.560
wireless lane controller is,

52
03:25.560 --> 03:30.360
except before wireless lane controllers existed, these clients were part of
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

52
03:25.560 --> 03:30.360
except before wireless lane controllers existed, these clients were part of

53
03:30.360 --> 03:31.720
whatever local network

54
03:32.280 --> 03:38.900
existed out here. They weren't part of another network. So if I have a site,

55
03:38.900 --> 03:39.720
for example,

56
03:39.720 --> 03:45.170
let's say I have a switched architecture here, I have an SVI and a gateway

57
03:45.170 --> 03:48.120
address for maybe VLAN 10,

58
03:48.120 --> 03:54.840
and this is where my wired clients go. Well, maybe I have another VLAN VLAN 20,

59
03:54.840 --> 04:02.640
and this connects my wireless clients. But either way, both of these subnets
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

59
03:54.840 --> 04:02.640
and this connects my wireless clients. But either way, both of these subnets

60
04:02.640 --> 04:04.680
live here on this layer

61
04:04.680 --> 04:09.380
three switch. Well, what did we just do here? We just said that our wireless

62
04:09.380 --> 04:10.520
clients aren't going to

63
04:10.520 --> 04:16.270
live here on this local VLAN 20 subnet, whatever that subnet is. Instead, this

64
04:16.270 --> 04:18.120
20 subnet will provide an

65
04:18.120 --> 04:24.950
IP address to the access point, but not to the wireless clients. These wireless

66
04:24.950 --> 04:26.040
clients are going to

67
04:26.040 --> 04:31.890
get tunneled through VLAN 20, through the layer three infrastructure, out to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

67
04:26.040 --> 04:31.890
get tunneled through VLAN 20, through the layer three infrastructure, out to

68
04:31.890 --> 04:33.000
wherever the wireless

69
04:33.000 --> 04:38.300
lane controller lives, and this is where the wireless stations are going to pop

70
04:38.300 --> 04:38.760
out.

71
04:38.760 --> 04:43.740
Tunneling is kind of funny. I like to think of it in terms of SIFI, because in

72
04:43.740 --> 04:44.440
SIFI worlds,

73
04:44.440 --> 04:50.840
like Star Trek, but either way, you see the ability to perform these kind of

74
04:50.840 --> 04:52.200
warps, where you just

75
04:52.200 --> 04:56.920
sort of pop out somewhere. And I can star wars they have that too. I digress, I

76
04:56.920 --> 04:57.400
'm not sure why we're

77
04:57.400 --> 05:02.120
getting into that conversation. Well, you've got this concept that you sort of
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

77
04:57.400 --> 05:02.120
getting into that conversation. Well, you've got this concept that you sort of

78
05:02.120 --> 05:03.560
disappear and you reappear

79
05:03.560 --> 05:08.520
somewhere else. And it's because you go so fast in the SIFI world that it's

80
05:08.520 --> 05:10.280
like you warp. You just

81
05:10.280 --> 05:14.540
disappear here, reappear here. In networking, that same concept applies, except

82
05:14.540 --> 05:15.240
it has nothing to do

83
05:15.240 --> 05:20.470
with speed. It has everything to do with the fact that the underlying network

84
05:20.470 --> 05:22.280
can't see the information.

85
05:22.280 --> 05:27.900
It's invisible to the network. And so we still warp the client traffic, which

86
05:27.900 --> 05:28.680
started here,

87
05:28.680 --> 05:34.860
pops up over here. Again, right here, when it shows back up on the network. Up
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

87
05:28.680 --> 05:34.860
pops up over here. Again, right here, when it shows back up on the network. Up

88
05:34.860 --> 05:35.480
until then,

89
05:35.480 --> 05:39.550
it was hidden inside of that tunnel. It's why we call it a tunnel is because

90
05:39.550 --> 05:40.680
the network can't see

91
05:40.680 --> 05:44.920
inside the tunnel until we pull that traffic outside of it and send it back to

92
05:44.920 --> 05:45.880
the network.

93
05:45.880 --> 05:51.720
So what exactly are we saying here? Why is this matter so much? Well, if we

94
05:51.720 --> 05:53.640
look at the architecture

95
05:53.640 --> 05:57.770
of saying I have a wireless LAN controller here, and this wireless LAN

96
05:57.770 --> 05:59.880
controller is part of a

97
05:59.880 --> 06:06.930
trunk infrastructure. So I'm trunking to a switch and I'm trunking the VLANs 10
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

97
05:59.880 --> 06:06.930
trunk infrastructure. So I'm trunking to a switch and I'm trunking the VLANs 10

98
06:06.930 --> 06:08.520
and 20 and 30,

99
06:08.520 --> 06:14.930
whatever VLANs I want to trunk over to it. Now I have to have SVIs here for

100
06:14.930 --> 06:16.280
these different VLANs.

101
06:16.280 --> 06:23.800
So let's say VLAN 30 is a wireless station or wireless client VLAN. So whatever

102
06:23.800 --> 06:24.920
subnet's associated

103
06:24.920 --> 06:31.620
with VLAN 30 here, I'm going to send my traffic through some kind of layer
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

103
06:24.920 --> 06:31.620
with VLAN 30 here, I'm going to send my traffic through some kind of layer

104
06:31.620 --> 06:33.320
three infrastructure,

105
06:33.320 --> 06:38.640
generally speaking, and I'm going to arrive on the wireless LAN controller. The

106
06:38.640 --> 06:39.160
wireless LAN

107
06:39.160 --> 06:45.460
controller, again, strips out the original packet and sends it down from a

108
06:45.460 --> 06:46.840
layer two perspective

109
06:46.840 --> 06:54.960
into the local network. Well, now this station that's all the way out here at

110
06:54.960 --> 06:56.520
some other location,

111
06:56.520 --> 07:02.580
some other site is now going to be using this SVI as its gateway. It's like it
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

111
06:56.520 --> 07:02.580
some other site is now going to be using this SVI as its gateway. It's like it

112
07:02.580 --> 07:04.040
's attached here

113
07:04.040 --> 07:10.230
from a logical perspective. Because if I am trying to get out to the internet,

114
07:10.230 --> 07:11.240
this station is going to

115
07:11.240 --> 07:18.890
have a destination MAC address of this gateway very far away from where it

116
07:18.890 --> 07:21.240
physically showed up on

117
07:21.240 --> 07:26.710
the network. So this is where the station physically lives. This is where the

118
07:26.710 --> 07:28.840
station logically lives.

119
07:28.840 --> 07:36.440
And this can be a really bad thing. For example, what if this is inside of my
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

119
07:28.840 --> 07:36.440
And this can be a really bad thing. For example, what if this is inside of my

120
07:36.440 --> 07:37.480
data center?

121
07:37.480 --> 07:44.170
Do I want any of my users to have direct connection into the data center

122
07:44.170 --> 07:48.760
network? No, I would never want my

123
07:48.760 --> 07:53.810
wired stations, let's say, to show up inside of the data center. I wouldn't

124
07:53.810 --> 07:55.240
want a user to be on

125
07:55.240 --> 08:01.230
the same VLAN as my servers or even on the same layer to switch as my servers.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

125
07:55.240 --> 08:01.230
the same VLAN as my servers or even on the same layer to switch as my servers.

126
08:01.230 --> 08:02.440
I would want segmentation

127
08:02.440 --> 08:07.300
there. Except doesn't it make sense for us to deploy the wireless line

128
08:07.300 --> 08:09.000
controller in a redundant

129
08:09.000 --> 08:13.730
location such as the data center? So if we decide to deploy the wireless line

130
08:13.730 --> 08:14.920
controller into the

131
08:14.920 --> 08:19.520
data center, now the wireless line controller here is connecting to a data

132
08:19.520 --> 08:20.520
center switch.

133
08:20.520 --> 08:26.760
And therefore the gateway and the subnet and the VLAN and all of these things

134
08:26.760 --> 08:27.960
that live on a data

135
08:27.960 --> 08:34.330
center switch are going to play host to our wireless stations. So this is why
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

135
08:27.960 --> 08:34.330
center switch are going to play host to our wireless stations. So this is why

136
08:34.330 --> 08:36.200
we need to pay attention

137
08:36.200 --> 08:40.610
to the wireless line controller location because the wireless subnets are going

138
08:40.610 --> 08:41.960
to exist where the

139
08:41.960 --> 08:46.680
WLC lives. So generally speaking, we don't actually want to deploy it into the

140
08:46.680 --> 08:48.120
data center. It's more

141
08:48.120 --> 08:52.670
common for us to want to deploy it into the distribution layer somewhere out on

142
08:52.670 --> 08:53.400
the network.

143
08:54.360 --> 08:58.440
But at the same time, this can get tricky because we might have a lot of

144
08:58.440 --> 08:59.800
distribution layers,

145
08:59.800 --> 09:04.680
a distribution block. So which one do we pick? Do we pick all of them? The
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

145
08:59.800 --> 09:04.680
a distribution block. So which one do we pick? Do we pick all of them? The

146
09:04.680 --> 09:05.880
conversation continues

147
09:05.880 --> 09:09.640
at that point, but this is a foundational concept that we need to understand

148
09:09.640 --> 09:12.440
about the flow of

149
09:12.440 --> 09:17.010
wireless traffic because it will impact where the wireless line controller gets

150
09:17.010 --> 09:17.800
deployed.

151
09:18.760 --> 09:26.480
Now the other reason we have to consider this is because we also need access to

152
09:26.480 --> 09:27.000
the wireless

153
09:27.000 --> 09:32.810
line controller. If an access point is communicating with the wireless line
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

153
09:27.000 --> 09:32.810
line controller. If an access point is communicating with the wireless line

154
09:32.810 --> 09:34.600
controller and it loses

155
09:34.600 --> 09:41.140
this connection, by default, a lightweight access point will go down because we

156
09:41.140 --> 09:42.360
just said a lot of

157
09:42.360 --> 09:47.610
the intelligence, the management, the configuration, all of the things that it

158
09:47.610 --> 09:48.920
was receiving from the

159
09:48.920 --> 09:53.770
wireless line controller it no longer has. And so the wireless line controller

160
09:53.770 --> 09:54.840
is going to

161
09:54.840 --> 10:01.080
shut down operations and try to find a new wireless line controller using those
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

161
09:54.840 --> 10:01.080
shut down operations and try to find a new wireless line controller using those

162
10:01.080 --> 10:01.880
discovery methods

163
10:01.880 --> 10:05.270
we talked about, which might be possible, but it also might not be possible

164
10:05.270 --> 10:06.280
depending on

165
10:06.280 --> 10:11.810
the situation here. We remote location and the whan link went down. If so, and

166
10:11.810 --> 10:12.200
there's no

167
10:12.200 --> 10:16.240
local wireless line controller, we're never going to find one, which means that

168
10:16.240 --> 10:17.000
our wireless

169
10:17.000 --> 10:21.480
environment is going to stay down. So we need to maintain access to the

170
10:21.480 --> 10:22.920
wireless line controller,

171
10:22.920 --> 10:28.070
which will again play a role in determining the location so that it's close to

172
10:28.070 --> 10:28.680
our wireless

173
10:28.680 --> 10:33.190
clients in some capacity and also that it's in a redundant location that's
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

173
10:28.680 --> 10:33.190
clients in some capacity and also that it's in a redundant location that's

174
10:33.190 --> 10:34.520
unlikely to go down.

175
10:34.520 --> 10:40.360
Now unfortunately, especially for remote locations, we might have a single whan

176
10:40.360 --> 10:41.640
link and

177
10:41.640 --> 10:48.960
survivability can be a concern. Fortunately Cisco does have an option for

178
10:48.960 --> 10:50.600
remote survivability,

179
10:50.600 --> 10:59.280
which is FlexConnect. FlexConnect maintains wireless line controller

180
10:59.280 --> 10:59.800
connectivity,

181
10:59.800 --> 11:08.530
but it does not use the wireless line controller for its data plane operations,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

181
10:59.800 --> 11:08.530
but it does not use the wireless line controller for its data plane operations,

182
11:08.530 --> 11:09.800
meaning it's not

183
11:09.800 --> 11:17.160
going to send data into the tunnels. The data stays local. And as such, we can

184
11:17.160 --> 11:18.120
stay online

185
11:18.120 --> 11:26.680
if the wireless line controller is down. This is a very important part of

186
11:26.680 --> 11:28.120
wireless designs,

187
11:28.120 --> 11:33.880
because I do not want to lose my wireless LAN necessarily, just because I lose
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

187
11:28.120 --> 11:33.880
because I do not want to lose my wireless LAN necessarily, just because I lose

188
11:33.880 --> 11:35.640
access to the controller.

189
11:35.640 --> 11:42.480
Now for larger infrastructure rich environments like our campus architectures,

190
11:42.480 --> 11:43.160
distribution and

191
11:43.160 --> 11:48.910
access, this isn't a concern, and we would never want to use FlexConnect for a

192
11:48.910 --> 11:50.040
lot of reasons. But

193
11:50.040 --> 11:54.120
as much as anything, Cisco just doesn't support that many FlexConnect access

194
11:54.120 --> 11:55.560
points all at once.

195
11:55.560 --> 12:01.180
We need to be looking at our remote sites for FlexConnect. And ultimately, what
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

195
11:55.560 --> 12:01.180
We need to be looking at our remote sites for FlexConnect. And ultimately, what

196
12:01.180 --> 12:02.200
we're going to find

197
12:02.200 --> 12:06.990
is that if they do lose access to the wireless line controller, they can stay

198
12:06.990 --> 12:08.440
online, which is very

199
12:08.440 --> 12:12.010
important for us for those remote sites that maybe don't have the best

200
12:12.010 --> 12:13.960
connections back to the network.