WEBVTT

1
00:00.000 --> 00:05.360
We just looked at a scenario where we integrated our access point in our

2
00:05.360 --> 00:06.400
wireless lane controllers

3
00:06.400 --> 00:08.040
into the SDA fabric.

4
00:08.040 --> 00:11.520
We called it a fabric access point in a fabric wireless lane controller.

5
00:11.520 --> 00:15.140
Well, believe it or not, there might be some situations where we say, "I don't

6
00:15.140 --> 00:15.640
want to

7
00:15.640 --> 00:18.920
integrate with the SDA fabric."

8
00:18.920 --> 00:20.840
There might be some good reasons for that.

9
00:20.840 --> 00:23.000
There might be some not-so-great reasons for that.

10
00:23.000 --> 00:24.840
It just depends on the scenario.

11
00:24.840 --> 00:29.860
But either way, we are able to deploy the wireless architecture, what we call

12
00:29.860 --> 00:31.000
over-the-top,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

12
00:29.860 --> 00:31.000
over-the-top,

13
00:31.000 --> 00:36.080
or wireless OTT, over the top of the SDA fabric.

14
00:36.080 --> 00:40.070
At that point, we're treating the SDA fabric as if it's just a layer or two set

15
00:40.070 --> 00:41.040
of switches.

16
00:41.040 --> 00:45.450
And I am going to use that set of switches to communicate between my access

17
00:45.450 --> 00:46.080
points and

18
00:46.080 --> 00:48.000
my wireless lane controller.

19
00:48.000 --> 00:55.130
So just like before, I'm going to attach my access points to the fabric edge

20
00:55.130 --> 00:56.160
nodes.

21
00:56.160 --> 01:03.250
But now I'm going to attach my wireless lane controller outside of the internal
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

21
00:56.160 --> 01:03.250
But now I'm going to attach my wireless lane controller outside of the internal

22
01:03.250 --> 01:03.920
border

23
01:03.920 --> 01:04.920
nodes.

24
01:04.920 --> 01:06.960
So notice, that's the first big change.

25
01:06.960 --> 01:16.040
This wireless lane controller is going to exist outside of the fabric.

26
01:16.040 --> 01:20.060
Because of this now, we are not performing registration with the control plane

27
01:20.060 --> 01:20.560
node for

28
01:20.560 --> 01:27.910
any of the wireless operations, nor are we going to form VXLAN tunnels here

29
01:27.910 --> 01:29.320
between the

30
01:29.320 --> 01:32.680
access point and the fabric edge node.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

30
01:29.320 --> 01:32.680
access point and the fabric edge node.

31
01:32.680 --> 01:37.160
That is only going to happen if we are fully fabric integrated.

32
01:37.160 --> 01:44.050
So again, when we're talking about wireless over-the-top, or OTT, we are truly

33
01:44.050 --> 01:44.840
saying

34
01:44.840 --> 01:51.520
that we're just going to layer wireless on top of this fabric architecture.

35
01:51.520 --> 01:56.530
So what we're going to do is we're going to maintain our CAPWAP communications

36
01:56.530 --> 01:57.080
for both

37
01:57.080 --> 02:02.040
control plane and data plane operations.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

37
01:57.080 --> 02:02.040
control plane and data plane operations.

38
02:02.040 --> 02:06.340
So all of my wireless station traffic will now go back into those CAPWAP

39
02:06.340 --> 02:07.200
tunnels.

40
02:07.200 --> 02:08.760
So what does this look like?

41
02:08.760 --> 02:15.170
Well, essentially, we're just going to layer our CAPWAP tunnels over the top of

42
02:15.170 --> 02:17.000
this architecture.

43
02:17.000 --> 02:20.300
We're going to form CAPWAP tunnels between every access point and the wireless

44
02:20.300 --> 02:20.560
lane

45
02:20.560 --> 02:26.380
controller, just like we do with any other Cisco lightweight wireless

46
02:26.380 --> 02:27.920
architecture.

47
02:27.920 --> 02:32.180
Now because this traffic hits the fabric edge node, the fabric edge node is
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

47
02:27.920 --> 02:32.180
Now because this traffic hits the fabric edge node, the fabric edge node is

48
02:32.180 --> 02:33.000
going to need

49
02:33.000 --> 02:36.000
to know how to get to that wireless lane controller.

50
02:36.000 --> 02:40.150
And so it's going to be important for the internal border node to take those

51
02:40.150 --> 02:40.780
wireless

52
02:40.780 --> 02:45.240
lane controller subnets, and we do need to perform registration for the

53
02:45.240 --> 02:46.040
wireless lane

54
02:46.040 --> 02:49.320
controller IP addresses into the fabric.

55
02:49.320 --> 02:54.240
So our control plane node down here will be useful because I can say, "Hey,

56
02:54.240 --> 02:54.960
where is the

57
02:54.960 --> 02:56.520
wireless lane controller IP?"

58
02:56.520 --> 03:00.240
And I get my answer and I forward it to the border node.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

58
02:56.520 --> 03:00.240
And I get my answer and I forward it to the border node.

59
03:00.240 --> 03:03.660
So keep that part in mind that we do need to register the wireless lane

60
03:03.660 --> 03:04.720
controller subnets

61
03:04.720 --> 03:07.520
into the fabric so that they can be reached.

62
03:07.520 --> 03:10.920
Otherwise, if we don't know where that subnet is, we'll get sent to the

63
03:10.920 --> 03:11.840
external border

64
03:11.840 --> 03:15.040
node and it'll get forwarded out to the internet.

65
03:15.040 --> 03:18.340
And then we will never see that traffic land on the wireless lane controller,

66
03:18.340 --> 03:18.800
and that's

67
03:18.800 --> 03:21.880
certainly not what we want here.

68
03:21.880 --> 03:24.000
So that's pretty much the extent of the conversation.

69
03:24.000 --> 03:28.120
If we're going to deploy wireless over the top, then we are deploying a

70
03:28.120 --> 03:29.400
traditional control

71
03:29.400 --> 03:35.220
plane and data plane, CAPWAP architecture, and we're just using SDA as a means
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

71
03:29.400 --> 03:35.220
plane and data plane, CAPWAP architecture, and we're just using SDA as a means

72
03:35.220 --> 03:36.400
to communicate

73
03:36.400 --> 03:39.880
between the access points and the wireless lane controllers.

74
03:39.880 --> 03:41.480
So why would we do this?

75
03:41.480 --> 03:44.760
What are the advantages of doing this type of architecture?

76
03:44.760 --> 03:47.600
Well, there are two primary reasons for doing this.

77
03:47.600 --> 03:56.890
One is just for the sake of migration assistance, meaning that if I want to

78
03:56.890 --> 03:58.760
migrate to SDA,

79
03:58.760 --> 04:04.650
when I'm changing all of my connections to access switches to layer three and I
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

79
03:58.760 --> 04:04.650
when I'm changing all of my connections to access switches to layer three and I

80
04:04.650 --> 04:04.960
'm doing

81
04:04.960 --> 04:09.300
all of this upgrade, I might not necessarily want to upgrade all of my wireless

82
04:09.300 --> 04:10.240
lane controllers

83
04:10.240 --> 04:14.660
and all of my access points and get everything all attached to the fabric all

84
04:14.660 --> 04:15.320
at the same

85
04:15.320 --> 04:16.320
time.

86
04:16.320 --> 04:21.120
So this allows for a phased approach to my SDA migration.

87
04:21.120 --> 04:27.200
I migrate to SDA first, and then I migrate my wireless.

88
04:27.200 --> 04:30.200
That's probably the biggest advantage to this.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

88
04:27.200 --> 04:30.200
That's probably the biggest advantage to this.

89
04:30.200 --> 04:38.010
The other aspect that we need to consider is that this supports legacy hardware

90
04:38.010 --> 04:38.320
.

91
04:38.320 --> 04:40.040
Remember those access points?

92
04:40.040 --> 04:45.800
They need to support VXLAN in order to be fabric supported.

93
04:45.800 --> 04:49.750
And Cisco started supporting VXLAN and specifically the hardware that is

94
04:49.750 --> 04:50.920
required in order to

95
04:50.920 --> 04:55.960
communicate via VXLAN in access points starting with specific models.

96
04:55.960 --> 04:59.800
If we have a more legacy architecture, we've had access points around for a

97
04:59.800 --> 05:00.440
little bit
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

97
04:59.800 --> 05:00.440
little bit

98
05:00.440 --> 05:01.520
longer.

99
05:01.520 --> 05:06.280
Maybe these access points don't actually support VXLAN, at which point we can't

100
05:06.280 --> 05:07.600
actually perform

101
05:07.600 --> 05:09.240
SDA fabric integration.

102
05:09.240 --> 05:14.160
I can't convert that access point to being a fabric AP.

103
05:14.160 --> 05:19.160
Now certainly they're the biggest downside to all of this, which is simply that

104
05:19.160 --> 05:19.640
I'm missing

105
05:19.640 --> 05:22.120
out on my fabric integration benefits.

106
05:22.120 --> 05:26.160
Some of that is simply managing all of this via catalyst center.

107
05:26.160 --> 05:32.190
So not only bringing the wired side under catalyst center, but also the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

107
05:26.160 --> 05:32.190
So not only bringing the wired side under catalyst center, but also the

108
05:32.190 --> 05:33.400
wireless.

109
05:33.400 --> 05:39.630
And we miss out on this, and that is certainly a downside to using wireless

110
05:39.630 --> 05:41.040
over the top.

111
05:41.040 --> 05:46.010
But we also do have to consider the fact that, so first of all, the lack of

112
05:46.010 --> 05:47.200
fabric integration

113
05:47.200 --> 05:51.920
and all of those benefits, but also traffic flow.

114
05:51.920 --> 05:58.080
So now our traffic flow has to leave the fabric, go external to the fabric, to

115
05:58.080 --> 05:58.640
the wireless

116
05:58.640 --> 06:05.040
LAN controller, and then back into the fabric for east and west flows.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

116
05:58.640 --> 06:05.040
LAN controller, and then back into the fabric for east and west flows.

117
06:05.040 --> 06:09.460
So if I want to communicate between a wireless device here, and maybe there's a

118
06:09.460 --> 06:10.200
printer on

119
06:10.200 --> 06:15.330
this access point over here, if I just want to communicate here east west style

120
06:15.330 --> 06:15.920
, well

121
06:15.920 --> 06:20.000
now I have to go out of the fabric and back into the fabric.

122
06:20.000 --> 06:25.060
Now this isn't a huge deal because we would have to do some amount of traffic t

123
06:25.060 --> 06:25.720
rombone

124
06:25.720 --> 06:31.070
ing, even if this wasn't an SDA conversation, because I form my tunnels to the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

124
06:25.720 --> 06:31.070
ing, even if this wasn't an SDA conversation, because I form my tunnels to the

125
06:31.070 --> 06:31.820
wireless

126
06:31.820 --> 06:37.140
LAN controller, I'd have to tunnel there, get forwarded back into the network,

127
06:37.140 --> 06:37.600
and end

128
06:37.600 --> 06:39.640
up wherever the access point is.

129
06:39.640 --> 06:43.220
However, in this situation it might be a little bit different, just because now

130
06:43.220 --> 06:43.520
we have

131
06:43.520 --> 06:48.210
to traverse a border node, and that might require us deploying the wireless LAN

132
06:48.210 --> 06:49.000
controllers

133
06:49.000 --> 06:52.560
a little bit further away than they would have otherwise been installed.

134
06:52.560 --> 06:57.300
And so we do need to consider the efficiency downside of the lack of efficiency

135
06:57.300 --> 06:58.200
by deploying

136
06:58.200 --> 07:00.000
wireless over the top.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

137
07:00.000 --> 07:04.080
But at least we know that it is an option in these situations where we say

138
07:04.080 --> 07:04.680
there are

139
07:04.680 --> 07:08.720
enough reasons for us to consider deploying wireless over the top, even if it's

140
07:08.720 --> 07:09.320
a temporary

141
07:09.320 --> 07:13.880
solution, and eventually we will migrate our wireless into the SDA fabric.