WEBVTT

1
00:00.000 --> 00:05.350
So the way I like to draw this out is to represent a layer three interface with

2
00:05.350 --> 00:06.120
a dot here.

3
00:06.120 --> 00:10.580
So we've got this layer three architecture between these two layer three

4
00:10.580 --> 00:11.380
devices.

5
00:11.380 --> 00:17.140
But meanwhile, I am creating an overlay that allows me to have a network here

6
00:17.140 --> 00:18.200
with a host.

7
00:18.200 --> 00:23.510
Let's say this is just host A operating on subnet A, but then we've also got

8
00:23.510 --> 00:24.580
this network

9
00:24.580 --> 00:30.700
over here with a different host B. But again, this is all the same subnet sub
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

9
00:24.580 --> 00:30.700
over here with a different host B. But again, this is all the same subnet sub

10
00:30.700 --> 00:31.540
net A here

11
00:31.540 --> 00:36.360
and subnet A here. With traditional networking, this is impossible. We can't

12
00:36.360 --> 00:36.980
actually have

13
00:36.980 --> 00:42.650
that. Both of these devices would claim to have access to subnet A. And only

14
00:42.650 --> 00:43.180
one of

15
00:43.180 --> 00:47.060
them would really win out and potentially both of them would win out as they

16
00:47.060 --> 00:47.500
talk to

17
00:47.500 --> 00:50.890
different parts of the network. So some of that traffic would land here and

18
00:50.890 --> 00:51.460
other that

19
00:51.460 --> 00:56.580
traffic would land here, it would just be a disaster. What we can do with VXLAN

20
00:56.580 --> 00:57.700
, if VXLAN

21
00:57.700 --> 01:03.100
is an option here to form a tunnel, is we can sort of put this dotted line
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

21
00:57.700 --> 01:03.100
is an option here to form a tunnel, is we can sort of put this dotted line

22
01:03.100 --> 01:03.660
between the

23
01:03.660 --> 01:08.280
two networks. And now we see that host A and host B are both part of the same

24
01:08.280 --> 01:08.820
network

25
01:08.820 --> 01:14.080
segment. And those are being shared via these two different devices, thanks to

26
01:14.080 --> 01:14.740
the VXLAN

27
01:14.740 --> 01:20.740
tunnel. So this is all again, thanks to VXLAN, which does stand for the virtual

28
01:20.740 --> 01:21.740
extensible

29
01:21.740 --> 01:26.490
local area network. So how exactly does it accomplish this? I mean, what

30
01:26.490 --> 01:27.420
exactly is

31
01:27.420 --> 01:34.430
VXLAN doing? Well, as with all tunneling mechanisms, it is a form of encaps
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

31
01:27.420 --> 01:34.430
VXLAN doing? Well, as with all tunneling mechanisms, it is a form of encaps

32
01:34.430 --> 01:37.900
ulation. And encapsulation,

33
01:37.900 --> 01:42.640
typically within the OSI model, we understand we take layer two encapsulate

34
01:42.640 --> 01:43.460
layer three

35
01:43.460 --> 01:47.150
into that and which has already encapsulated layer four and all of these things

36
01:47.150 --> 01:47.940
. But we're

37
01:47.940 --> 01:53.950
talking about tunneling, we add extra encapsulation. And VXLAN specifically is

38
01:53.950 --> 01:55.180
going to be known

39
01:55.180 --> 02:02.950
as Mac in UDP, actually technically we're right IP slash UDP here. So what we
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

39
01:55.180 --> 02:02.950
as Mac in UDP, actually technically we're right IP slash UDP here. So what we

40
02:02.950 --> 02:03.420
're looking

41
02:03.420 --> 02:08.360
at is encapsulating not only the Mac address, but we're going to use IP and UDP

42
02:08.360 --> 02:08.980
in order

43
02:08.980 --> 02:17.180
to do that. And specifically, we're going to use UDP or 4789. But once again,

44
02:17.180 --> 02:18.020
as always,

45
02:18.020 --> 02:21.700
we might need to make sure that that port is open if we're passing through a

46
02:21.700 --> 02:22.260
layer three

47
02:22.260 --> 02:28.980
device, that is filtering ports. So we're going to see an increase in MTU here.

48
02:28.980 --> 02:29.340
The increase

49
02:29.340 --> 02:35.500
in MTU is going to go up by 50 bytes. So long as we're not carrying a dot one
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

49
02:29.340 --> 02:35.500
in MTU is going to go up by 50 bytes. So long as we're not carrying a dot one

50
02:35.500 --> 02:36.380
queue header.

51
02:36.380 --> 02:40.030
For the most part, we don't do that within VXLAN. Just understand if we add

52
02:40.030 --> 02:40.740
four bytes

53
02:40.740 --> 02:44.900
to the ethernet frame that we're carrying, and we're carrying that dot one

54
02:44.900 --> 02:45.580
queue header

55
02:45.580 --> 02:53.400
with us, it would be 54 bytes. So 54 with 802.1 queue. But for the most part,

56
02:53.400 --> 02:54.180
we don't

57
02:54.180 --> 03:00.280
actually need this extra tag. For the most part, we don't carry the 802.1 queue
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

57
02:54.180 --> 03:00.280
actually need this extra tag. For the most part, we don't carry the 802.1 queue

58
03:00.280 --> 03:00.660
within

59
03:00.660 --> 03:05.480
VXLAN. There's really just not a strong use case for doing so. Because the VX

60
03:05.480 --> 03:06.180
LAN identifier

61
03:06.180 --> 03:11.580
carries the VLAN identifier sort of within it. So all that to say, understand

62
03:11.580 --> 03:12.020
that we

63
03:12.020 --> 03:17.140
do need to increase VMTU. And once again, that VXLAN identifier is very

64
03:17.140 --> 03:18.700
important. So

65
03:18.700 --> 03:23.100
sometimes called a VXLAN network identifier, virtual network identifier. But

66
03:23.100 --> 03:23.940
either way,

67
03:23.940 --> 03:33.090
it's that VNI or sometimes the VNID that we talk about having 24 bits. So now
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

67
03:23.940 --> 03:33.090
it's that VNI or sometimes the VNID that we talk about having 24 bits. So now

68
03:33.090 --> 03:33.580
what we

69
03:33.580 --> 03:38.630
can do is we can expand our data centers and expand our environments to say

70
03:38.630 --> 03:39.500
that now we've

71
03:39.500 --> 03:46.960
got plenty of these identifiers. And so that creates again that 16.7 million

72
03:46.960 --> 03:48.180
network segments.

73
03:48.180 --> 03:52.500
We don't have to worry about running out of VLAN IDs for very large

74
03:52.500 --> 03:53.820
environments. So

75
03:53.820 --> 04:01.110
what this ends up looking like is this. We take the entire layer two frame,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

75
03:53.820 --> 04:01.110
what this ends up looking like is this. We take the entire layer two frame,

76
04:01.110 --> 04:01.540
meaning that

77
04:01.540 --> 04:06.790
we've got the ethernet header still in there. And then whatever we're carrying

78
04:06.790 --> 04:07.860
in here,

79
04:07.860 --> 04:13.740
probably IP or IP version four, IP version six, TCP or UDP at layer four,

80
04:13.740 --> 04:14.860
whatever the

81
04:14.860 --> 04:19.650
payload ends up being in here. So we've got lots and lots of data inside this

82
04:19.650 --> 04:20.180
layer two

83
04:20.180 --> 04:26.500
frame. And by the way, don't forget that we've got that FCS at the end. So we

84
04:26.500 --> 04:26.780
've got the

85
04:26.780 --> 04:32.020
entire thing. And then what we're going to do is we're going to treat this like
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

85
04:26.780 --> 04:32.020
entire thing. And then what we're going to do is we're going to treat this like

86
04:32.020 --> 04:32.300
it's

87
04:32.300 --> 04:39.740
itself a payload for VXLAN. And so what we're going to do is we're going to add

88
04:39.740 --> 04:40.740
on a VX

89
04:40.740 --> 04:47.500
LAN header. And that VXLAN header is eight bytes. But we've got to then add on

90
04:47.500 --> 04:47.940
a new

91
04:47.940 --> 04:52.850
outer IP header and outer layer four header as well. So this is where we say it

92
04:52.850 --> 04:53.260
's an

93
04:53.260 --> 04:57.780
IP and UDP, because we're going to add a UDP header here, which is another

94
04:57.780 --> 04:58.860
eight bytes.

95
04:58.860 --> 05:02.540
And then we're going to have to add an outer IP header. So that's 20 bytes. So
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

95
04:58.860 --> 05:02.540
And then we're going to have to add an outer IP header. So that's 20 bytes. So

96
05:02.540 --> 05:03.180
that's up

97
05:03.180 --> 05:10.630
to 36 at this point. And then we have finally our outer ethernet header, which

98
05:10.630 --> 05:11.460
comes at

99
05:11.460 --> 05:16.510
an additional 14 bytes, 12 of which is the source and destination MAC address.

100
05:16.510 --> 05:16.980
So this

101
05:16.980 --> 05:21.250
is where we can see that we need an additional 50 bytes. And we add that all up

102
05:21.250 --> 05:21.980
. And if we

103
05:21.980 --> 05:28.030
wanted the dot one queue header inside of, well, in here at this point, then

104
05:28.030 --> 05:28.980
that would

105
05:28.980 --> 05:34.370
actually add four extra bytes. Because this payload, before we encapsulated it,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

105
05:28.980 --> 05:34.370
actually add four extra bytes. Because this payload, before we encapsulated it,

106
05:34.370 --> 05:34.660
this was

107
05:34.660 --> 05:40.820
fully ready for the 1500 bytes of, or you know, for using Jumbo frames fine,

108
05:40.820 --> 05:41.500
but just

109
05:41.500 --> 05:46.740
in a standard environment, that would be the 1500 bytes. And ethernet, header

110
05:46.740 --> 05:47.620
and trailer,

111
05:47.620 --> 05:51.800
those don't count towards and you know, the, the MTU themselves. Well, now that

112
05:51.800 --> 05:52.300
they're

113
05:52.300 --> 05:57.610
part of the payload, they do. And so that's why we need to count the extra

114
05:57.610 --> 05:58.820
headers. And

115
05:58.820 --> 06:02.080
if we want to think of it this way, the headers again, maybe the headers don't
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

115
05:58.820 --> 06:02.080
if we want to think of it this way, the headers again, maybe the headers don't

116
06:02.080 --> 06:03.740
count up here.

117
06:03.740 --> 06:07.670
But it's the inner headers that do because they're now part of the payload or

118
06:07.670 --> 06:08.500
like this.

119
06:08.500 --> 06:11.760
So however, when I think of it is fine. But again, we do see that we need an

120
06:11.760 --> 06:12.420
additional

121
06:12.420 --> 06:17.520
50 bytes. So we've created a bit of a monster of a frame that we're going to

122
06:17.520 --> 06:18.220
send from one

123
06:18.220 --> 06:23.370
device to another. So these devices have a name, by the way, at this point,

124
06:23.370 --> 06:23.740
they are

125
06:23.740 --> 06:35.950
known as virtual tunnel endpoints, otherwise known as V taps. The V taps are
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

125
06:23.740 --> 06:35.950
known as virtual tunnel endpoints, otherwise known as V taps. The V taps are

126
06:35.950 --> 06:36.740
one of two

127
06:36.740 --> 06:41.600
things we can think of them. Typically, the V taps are referred to as the end

128
06:41.600 --> 06:43.060
points themselves,

129
06:43.060 --> 06:48.140
the device. So this device here, for example, would be a V tap. And so with

130
06:48.140 --> 06:49.300
this device over

131
06:49.300 --> 06:53.380
here, we have two different switches running the X land. And each of them would

132
06:53.380 --> 06:53.860
be known

133
06:53.860 --> 06:58.690
as a V tap. We can also think of the V tap as the actual IP interface. And we

134
06:58.690 --> 06:58.900
'll see

135
06:58.900 --> 07:05.260
conversations and white papers talking about both of these. But the reality is
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

135
06:58.900 --> 07:05.260
conversations and white papers talking about both of these. But the reality is

136
07:05.260 --> 07:05.620
that just

137
07:05.620 --> 07:10.740
like with any other tunnel, such as GRE tunnels, we're going to need to form

138
07:10.740 --> 07:11.860
the VX land tunnel

139
07:11.860 --> 07:19.820
from one layer three interface to another. So this is typically going to be a

140
07:19.820 --> 07:21.220
loopback interface

141
07:21.220 --> 07:28.780
on the device. So here's my physical switch. Here's another physical switch.

142
07:28.780 --> 07:29.460
And we're forming

143
07:29.460 --> 07:37.140
the VX land tunnel via loopback from one device to the other. Now our V taps
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

143
07:29.460 --> 07:37.140
the VX land tunnel via loopback from one device to the other. Now our V taps

144
07:37.140 --> 07:37.940
are switches. Now,

145
07:37.940 --> 07:42.310
if we think of it like that, are going to have not only a virtual interface

146
07:42.310 --> 07:43.540
like this, but we're

147
07:43.540 --> 07:47.800
also going to have what's known as a local area network interface. And that

148
07:47.800 --> 07:48.420
would be the

149
07:48.420 --> 07:52.690
connection into the layer two world. This world is going to continue to use V

150
07:52.690 --> 07:53.220
lands,

151
07:53.780 --> 07:58.340
which is kind of interesting because yeah, we've got all these identifiers, the

152
07:58.340 --> 08:00.020
16.7 million
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

152
07:58.340 --> 08:00.020
16.7 million

153
08:00.020 --> 08:05.840
identifiers between our switches. But southbound of one of these switches, this

154
08:05.840 --> 08:07.140
is itself still a

155
08:07.140 --> 08:12.620
classic layer two domain, meaning we can only still have those 4000 identifiers

156
08:12.620 --> 08:13.780
. Now, I don't

157
08:13.780 --> 08:19.590
know about you, 4000 identifiers on a single switch. That's plenty for me. I

158
08:19.590 --> 08:20.980
don't think

159
08:20.980 --> 08:25.700
I we're not even going to have that many ports. We could not possibly use 4000

160
08:25.700 --> 08:26.660
identifiers on a

161
08:26.660 --> 08:33.180
single physical switch. Meanwhile, the VX land in the middle, this identifier
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

161
08:26.660 --> 08:33.180
single physical switch. Meanwhile, the VX land in the middle, this identifier

162
08:33.180 --> 08:34.340
that VNI is sort of

163
08:34.340 --> 08:40.160
the glue that connects two different V land identifiers. And what's interesting

164
08:40.160 --> 08:40.900
is in the V

165
08:40.900 --> 08:46.250
land world or the VX land world, rather, we can find that we can glue together

166
08:46.250 --> 08:47.300
two different V

167
08:47.300 --> 08:52.040
land IDs. So going back to the top left here, VX land, maybe we have an

168
08:52.040 --> 08:54.260
identifier of 10567.

169
08:54.260 --> 08:59.440
This is the VNI or the V-NID for this connection. When a packet gets sent and

170
08:59.440 --> 09:00.980
encapsulated in VX
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

170
08:59.440 --> 09:00.980
encapsulated in VX

171
09:00.980 --> 09:05.400
land, it's going to include this identifier. So the receiving switch knows

172
09:05.400 --> 09:06.180
which layer two

173
09:06.180 --> 09:12.140
domain to connect together. But meanwhile, what V land identifiers are on each

174
09:12.140 --> 09:13.380
one of these

175
09:13.380 --> 09:18.660
network segments? We might say, well, let's just go ahead and assign VLAN 105

176
09:18.660 --> 09:20.100
or something like that

177
09:20.100 --> 09:26.180
to the VLAN identifier or to the VLAN on the left. So, okay, so if I'm tagging

178
09:26.180 --> 09:27.140
traffic coming in

179
09:27.140 --> 09:32.200
here, it would have to be VLAN 105. But what about the switch on the right?
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

179
09:27.140 --> 09:32.200
here, it would have to be VLAN 105. But what about the switch on the right?

180
09:32.200 --> 09:33.060
Well, we say, well,

181
09:33.060 --> 09:39.520
of course, it would have to be 105, right? Well, it doesn't. This could be 1536

182
09:39.520 --> 09:41.940
. It doesn't matter

183
09:41.940 --> 09:46.370
that these don't match because remember what we said, for the most part, we don

184
09:46.370 --> 09:47.620
't actually include

185
09:47.620 --> 09:52.500
the tag. And this is one of the reasons why, because if I'm going to have these

186
09:52.500 --> 09:53.300
identifiers,

187
09:53.300 --> 09:57.390
there we go, if we're going to have these different identifiers, where they

188
09:57.390 --> 09:58.740
have to lock in and be

189
09:58.740 --> 10:03.710
the exact same identifier, I've kind of eliminated the value of having all of
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

189
09:58.740 --> 10:03.710
the exact same identifier, I've kind of eliminated the value of having all of

190
10:03.710 --> 10:05.060
these different VNI's.

191
10:05.060 --> 10:09.540
Instead, what I've done is I've freed up each switch to use its VLAN

192
10:09.540 --> 10:10.500
identifiers,

193
10:10.500 --> 10:18.260
however it wants. So, I can assign VLAN 105 to this network here, and then this

194
10:18.260 --> 10:18.820
switch over here

195
10:18.820 --> 10:23.200
has the total freedom to do whatever it wants with its VLAN identifiers. And so

196
10:23.200 --> 10:24.420
, it decides to assign

197
10:24.420 --> 10:31.300
1536 here. Again, if I lock it in to say 105 must be used over here, well, then
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

197
10:24.420 --> 10:31.300
1536 here. Again, if I lock it in to say 105 must be used over here, well, then

198
10:31.300 --> 10:32.260
it kind of has to

199
10:32.260 --> 10:37.210
be used everywhere. And so, if I have to kind of use it everywhere, then I've

200
10:37.210 --> 10:38.820
locked up that one

201
10:38.820 --> 10:43.300
VLAN identifier everywhere. And again, I'm going to quickly run out again. I

202
10:43.300 --> 10:44.100
can't just say I'm

203
10:44.100 --> 10:47.940
going to lock up the 4000 VLAN identifiers, because that's what I'm trying to

204
10:47.940 --> 10:48.660
get away from.

205
10:48.660 --> 10:54.260
So, this is why we say we have 4000 on each switch. I have 4000 here and 4000

206
10:54.260 --> 10:54.820
here. I can use

207
10:54.820 --> 11:01.540
them however I want. And also, coming back to this term, the VNI is what glues
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

207
10:54.820 --> 11:01.540
them however I want. And also, coming back to this term, the VNI is what glues

208
11:01.540 --> 11:02.900
them together,

209
11:02.900 --> 11:08.190
and allows the switches to know, hey, I just received this identifier from VX

210
11:08.190 --> 11:09.140
LAN, and I know

211
11:09.140 --> 11:15.510
that that belongs on my side to VLAN 1536. And I don't care that the other side

212
11:15.510 --> 11:15.940
thinks that it

213
11:15.940 --> 11:20.670
belongs to their VLAN 105, so long that it's these network segments that I'm

214
11:20.670 --> 11:22.260
connecting together.

215
11:22.260 --> 11:30.710
Now, a very important part about VXLAN is to understand that VXLAN only exists
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

215
11:22.260 --> 11:30.710
Now, a very important part about VXLAN is to understand that VXLAN only exists

216
11:30.710 --> 11:32.020
as a data plane

217
11:32.020 --> 11:38.290
protocol. This is a data plane only situation. Now, if we think about it, what

218
11:38.290 --> 11:39.220
we usually have

219
11:39.220 --> 11:43.380
is we have a control plane that feeds information

220
11:43.380 --> 11:52.420
into a device that allows it to perform data plane operations, meaning I bring

221
11:52.420 --> 11:53.860
a packet into

222
11:53.860 --> 11:59.590
this port, and I know to send it out this port. So, data plane operations are

223
11:59.590 --> 12:00.980
enabled by the control
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

223
11:59.590 --> 12:00.980
enabled by the control

224
12:00.980 --> 12:05.420
plane. But we just said that we don't have this control plane, meaning I don't

225
12:05.420 --> 12:06.100
have a bunch of

226
12:06.100 --> 12:13.020
information as to being fed to me as to where to send this information. So,

227
12:13.020 --> 12:13.860
what do we do here?

228
12:13.860 --> 12:17.700
Well, we could ask the same question about Ethernet. How does Ethernet work?

229
12:17.700 --> 12:18.420
Because Ethernet

230
12:18.420 --> 12:23.060
certainly has data plane operations, but we don't have a protocol sharing where

231
12:23.060 --> 12:24.020
all the MAC addresses

232
12:24.020 --> 12:29.300
are. Well, the way Ethernet works is exactly how VXLAN is going to work. It's

233
12:29.300 --> 12:30.500
going to use a flood
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

233
12:29.300 --> 12:30.500
going to use a flood

234
12:30.500 --> 12:35.730
and learn methodology, meaning that when that first packet arrives, I am going

235
12:35.730 --> 12:37.380
to send it out all of

236
12:37.380 --> 12:41.860
my interfaces. And when we think about what we're really saying here is I'm

237
12:41.860 --> 12:43.860
sending it to all of my

238
12:43.860 --> 12:48.730
VXLAN peers. So, I'm going to flood that. And in our case, because we're

239
12:48.730 --> 12:50.420
flooding it across layer

240
12:50.420 --> 12:55.120
three to all of my peers, I'm going to rely on multicast in order to do this.

241
12:55.120 --> 12:56.020
If I multicast

242
12:56.020 --> 13:00.500
it to all my peers, it gets flooded out all the ports. And eventually, I am
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

242
12:56.020 --> 13:00.500
it to all my peers, it gets flooded out all the ports. And eventually, I am

243
13:00.500 --> 13:02.020
going to receive a

244
13:02.020 --> 13:08.340
response. And once I receive a response, I am going to track this. And so, I

245
13:08.340 --> 13:10.340
still will store a data

246
13:10.340 --> 13:15.190
table so that I can eventually become more efficient. But we do see that this

247
13:15.190 --> 13:16.020
is not super

248
13:16.020 --> 13:20.180
efficient on its own. VXLAN is going to rely on flood and learn, and then there

249
13:20.180 --> 13:20.980
's going to be a

250
13:20.980 --> 13:25.500
whole lot of flooding before the learning occurs. So, what are our options here

251
13:25.500 --> 13:27.060
? Well, VXLAN does,

252
13:27.060 --> 13:33.080
unlike Ethernet, allow us to be paired up. So, we can pair up VXLAN with a
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

252
13:27.060 --> 13:33.080
unlike Ethernet, allow us to be paired up. So, we can pair up VXLAN with a

253
13:33.080 --> 13:34.900
control plane protocol.

254
13:34.900 --> 13:40.900
And we have several that we can take a look at here. Typically, multi protocol

255
13:40.900 --> 13:41.940
BGP is going to be

256
13:41.940 --> 13:45.910
a popular choice. We use this pretty much any time we're configuring this

257
13:45.910 --> 13:48.020
ourselves. If we're not

258
13:48.020 --> 13:52.180
using a pre-packaged software-defined networking solution, we're probably going

259
13:52.180 --> 13:53.300
to use multi-protocol

260
13:53.300 --> 14:01.940
BGP, which is known as BGP EVPN. So, Ethernet VPN is how we refer to that. Now,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

260
13:53.300 --> 14:01.940
BGP, which is known as BGP EVPN. So, Ethernet VPN is how we refer to that. Now,

261
14:01.940 --> 14:02.660
we also have a

262
14:02.660 --> 14:07.420
couple of Cisco options. First of all, application-centric infrastructure,

263
14:07.420 --> 14:09.140
which is Cisco's SDN

264
14:09.140 --> 14:14.140
software or SDN platform for the data center. This is going to use a different

265
14:14.140 --> 14:15.060
protocol known

266
14:15.060 --> 14:21.380
as the Council of Oracle Protocol or Koop. And furthermore, importantly, as we

267
14:21.380 --> 14:22.900
keep coming back to,

268
14:22.900 --> 14:27.540
software-defined access also does not want to rely on flood and learn. So, what

269
14:27.540 --> 14:27.940
does software

270
14:27.940 --> 14:35.940
define access use? It uses LISP at the control plane. And so, VXLAN itself can
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

270
14:27.940 --> 14:35.940
define access use? It uses LISP at the control plane. And so, VXLAN itself can

271
14:35.940 --> 14:36.740
operate without a

272
14:36.740 --> 14:41.370
control plane, but we definitely want to map a control plane to it, which just

273
14:41.370 --> 14:42.420
overall increases

274
14:42.420 --> 14:45.780
is the efficiency of VXLAN operations.