WEBVTT

1
00:00.000 --> 00:05.400
So, our situation is once again that a packet has arrived here on this edge

2
00:05.400 --> 00:06.480
node, destined

3
00:06.480 --> 00:12.090
for host B, and the edge node here reached out to the control plane node and

4
00:12.090 --> 00:13.640
now has learned

5
00:13.640 --> 00:15.240
where host B lives.

6
00:15.240 --> 00:19.460
It lives on this edge over here and we used Lisp in order to learn that

7
00:19.460 --> 00:20.680
information using

8
00:20.680 --> 00:22.480
that pole methodology.

9
00:22.480 --> 00:26.240
I have pulled that information down and now I know where to send it.

10
00:26.240 --> 00:27.800
Well, here's the problem.

11
00:27.800 --> 00:33.500
I have a packet with a destination of host B, which means I can send it here
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

11
00:27.800 --> 00:33.500
I have a packet with a destination of host B, which means I can send it here

12
00:33.500 --> 00:34.040
and in

13
00:34.040 --> 00:38.520
a traditional network that would be no problem other than the fact that now

14
00:38.520 --> 00:39.600
this device and

15
00:39.600 --> 00:43.200
this device also need to know where host B is.

16
00:43.200 --> 00:47.820
If I just forward this packet to this layer 3 device in the middle, it's going

17
00:47.820 --> 00:48.400
to check

18
00:48.400 --> 00:52.880
its own routing table for the destination host B and it's going to learn where

19
00:52.880 --> 00:53.200
it is

20
00:53.200 --> 00:54.680
and send it on.

21
00:54.680 --> 00:58.870
So now we're asking these devices in the middle to have that full routing table

22
00:58.870 --> 00:59.560
experience

23
00:59.560 --> 01:01.720
that we just said we don't want.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

23
00:59.560 --> 01:01.720
that we just said we don't want.

24
01:01.720 --> 01:05.250
We don't want our edge devices to know all of that information and have to

25
01:05.250 --> 01:06.360
store it all.

26
01:06.360 --> 01:10.780
We have this database of information here on the control plane node instead and

27
01:10.780 --> 01:11.200
so we'd

28
01:11.200 --> 01:15.160
really rather not have to know that information.

29
01:15.160 --> 01:19.280
And so that's exactly what we're going to want to build out here is a tunneling

30
01:19.280 --> 01:19.920
mechanism

31
01:19.920 --> 01:25.740
where these devices in the middle don't know where host B is and yet they will

32
01:25.740 --> 01:27.680
happily facilitate

33
01:27.680 --> 01:32.560
our communications path from edge device to edge device.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

33
01:27.680 --> 01:32.560
our communications path from edge device to edge device.

34
01:32.560 --> 01:34.440
So what do they need to know?

35
01:34.440 --> 01:39.680
Well, we had pointed out before that maybe this edge device here has an R lock

36
01:39.680 --> 01:40.260
in list

37
01:40.260 --> 01:45.800
terms or an IP address of 10.1.1.1.

38
01:45.800 --> 01:51.200
So they don't need to know where B is but they do need to know where this is.

39
01:51.200 --> 01:56.220
So they need to know where 10.1.1.1 is or have an equivalent subnet and that

40
01:56.220 --> 01:56.940
information

41
01:56.940 --> 02:00.300
needs to exist in both of their routing tables.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

41
01:56.940 --> 02:00.300
needs to exist in both of their routing tables.

42
02:00.300 --> 02:07.410
This way I can build a packet now that has a destination of 10.1.1.1, send it

43
02:07.410 --> 02:07.960
into the

44
02:07.960 --> 02:12.360
network and allow the network to carry it to the edge device.

45
02:12.360 --> 02:16.160
But we have a problem, we have two different destinations.

46
02:16.160 --> 02:20.630
I need them to look at this outer destination, this destination that I'm really

47
02:20.630 --> 02:21.280
asking them

48
02:21.280 --> 02:27.800
to look at and get me to this 10.1.1.1 and I don't want them looking at the

49
02:27.800 --> 02:28.960
destination

50
02:28.960 --> 02:33.880
that says I'm trying to get to host B because they don't know where B lives.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

50
02:28.960 --> 02:33.880
that says I'm trying to get to host B because they don't know where B lives.

51
02:33.880 --> 02:37.200
Well we have a very simple way in the networking world in order to have

52
02:37.200 --> 02:38.480
multiple destinations

53
02:38.480 --> 02:43.220
and to only look at one of them, namely the outer one that just mentioned and

54
02:43.220 --> 02:43.700
that would

55
02:43.700 --> 02:46.400
be the concept of the tunnel.

56
02:46.400 --> 02:52.680
So I can take my original frame here and this frame can be destined for 10,

57
02:52.680 --> 02:53.740
well actually

58
02:53.740 --> 02:57.970
this one will, we didn't give an IP address to host B. So it's destined for

59
02:57.970 --> 02:58.820
host B. This

60
02:58.820 --> 03:00.920
would be in the IP header here.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

60
02:58.820 --> 03:00.920
would be in the IP header here.

61
03:00.920 --> 03:06.700
We still got our payload here of whatever information host A is just trying to

62
03:06.700 --> 03:07.400
get over

63
03:07.400 --> 03:11.450
to host B and we're going to wrap all of this up in a new header which has a

64
03:11.450 --> 03:12.240
destination

65
03:12.240 --> 03:19.600
of 10.1.1.1 and we're going to send this information out.

66
03:19.600 --> 03:25.670
So now we are effectively building a tunnel through the SDA fabric to get to

67
03:25.670 --> 03:27.520
the other side

68
03:27.520 --> 03:32.240
and because these devices in the middle are not going to de-incapsulate it,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

68
03:27.520 --> 03:32.240
and because these devices in the middle are not going to de-incapsulate it,

69
03:32.240 --> 03:33.160
they're only

70
03:33.160 --> 03:38.520
going to look here at the outer header to try to get us to the ultimate

71
03:38.520 --> 03:39.800
destination which

72
03:39.800 --> 03:46.160
is B but they don't know where going to be because this is the inner header.

73
03:46.160 --> 03:48.400
Now we've accomplished something pretty great.

74
03:48.400 --> 03:54.580
Neither the edge nodes nor the nodes in the middle need to know where host B is

75
03:54.580 --> 03:54.600
.

76
03:54.600 --> 03:58.850
The only device that has to know where B is for all of this to work is the

77
03:58.850 --> 04:00.000
control plane
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

78
04:00.000 --> 04:00.800
node.

79
04:00.800 --> 04:06.640
If the control plane node knows where all of these hosts are then the edge

80
04:06.640 --> 04:07.800
nodes can pull

81
04:07.800 --> 04:12.790
that information down on an as needed basis and meanwhile the underlay devices

82
04:12.790 --> 04:13.240
in the

83
04:13.240 --> 04:18.330
middle they don't ever need to know where host B lives nor do they need to know

84
04:18.330 --> 04:19.480
where any

85
04:19.480 --> 04:23.440
of the hosts live in this architecture.

86
04:23.440 --> 04:28.380
But we once again come to another problem which is right here we have said that

87
04:28.380 --> 04:28.840
we are

88
04:28.840 --> 04:31.560
extending our subnets.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

88
04:28.840 --> 04:31.560
extending our subnets.

89
04:31.560 --> 04:36.380
If we're extending our subnets then this means that this is going to require a

90
04:36.380 --> 04:36.860
layer

91
04:36.860 --> 04:44.450
to tunnel because this is effectively saying we're going to stretch VLAN 10 or

92
04:44.450 --> 04:45.140
maybe it's

93
04:45.140 --> 04:50.630
VLAN 100 since we have a 100 in there but we'll call it VLAN 100 so VLAN 100

94
04:50.630 --> 04:51.320
now needs

95
04:51.320 --> 04:55.660
to stretch between these two edge devices which makes sense because remember

96
04:55.660 --> 04:56.160
this is

97
04:56.160 --> 05:03.200
a campus architecture and these are simply access layer switches.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

97
04:56.160 --> 05:03.200
a campus architecture and these are simply access layer switches.

98
05:03.200 --> 05:07.580
If I'm building out my fabric we have said that we want my access switches to

99
05:07.580 --> 05:08.160
all have

100
05:08.160 --> 05:13.770
layer 2 connectivity among them even though they are now layer 3 separated by

101
05:13.770 --> 05:14.120
whatever

102
05:14.120 --> 05:17.740
these devices are here in the middle maybe it's just a pair of physical

103
05:17.740 --> 05:19.000
distribution switches

104
05:19.000 --> 05:24.920
that are now operating as a layer 3 underlay to connect my edge access layer

105
05:24.920 --> 05:25.680
switches.

106
05:25.680 --> 05:31.680
So because I want layer 2 to be extended I actually need to carry the ethernet
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

106
05:25.680 --> 05:31.680
So because I want layer 2 to be extended I actually need to carry the ethernet

107
05:31.680 --> 05:32.880
header as part

108
05:32.880 --> 05:34.600
of this tunnel.

109
05:34.600 --> 05:40.010
Notice I left that on there we are actually going to encapsulate the entirety

110
05:40.010 --> 05:40.760
of the layer

111
05:40.760 --> 05:42.760
2 frame.

112
05:42.760 --> 05:46.460
Most tunnel mechanisms are layer 3 meaning they're not going to carry the ether

113
05:46.460 --> 05:47.160
net frame they'll

114
05:47.160 --> 05:52.320
just carry the inner TCP/IP or UDP/IP layer 3 header.

115
05:52.320 --> 05:56.490
But in this case we do need to take the layer 2 header with us so we can carry

116
05:56.490 --> 05:57.080
the entire

117
05:57.080 --> 05:58.720
layer 2 frame.

118
05:58.720 --> 06:04.320
If host A and host B for example are on the same subnet then I'm probably
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

118
05:58.720 --> 06:04.320
If host A and host B for example are on the same subnet then I'm probably

119
06:04.320 --> 06:05.920
sending to host

120
06:05.920 --> 06:06.920
B's MAC address.

121
06:06.920 --> 06:12.830
I have a destination MAC address of host B and that needs to be maintained here

122
06:12.830 --> 06:13.480
inside

123
06:13.480 --> 06:15.200
the layer 2 frame.

124
06:15.200 --> 06:18.520
So we need a layer 2 tunnel how are we going to do this?

125
06:18.520 --> 06:24.440
So we're going to use a special protocol known as VXLAN.

126
06:24.440 --> 06:29.020
Which looks a lot like VLAN except this X here actually stands for extensible

127
06:29.020 --> 06:29.520
so it's

128
06:29.520 --> 06:33.200
the virtual extensible local area network.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

128
06:29.520 --> 06:33.200
the virtual extensible local area network.

129
06:33.200 --> 06:38.970
VXLAN is a tunnel mechanism that can carry layer 2 information so it builds

130
06:38.970 --> 06:39.880
actual layer

131
06:39.880 --> 06:41.560
2 tunnels.

132
06:41.560 --> 06:46.640
This tunnel therefore that we built up here between our edge devices this is

133
06:46.640 --> 06:47.400
now going

134
06:47.400 --> 06:51.320
to be a VXLAN tunnel.

135
06:51.320 --> 06:57.300
Now specifically within the world of Cisco's SDA we're going to use a flavor of

136
06:57.300 --> 06:58.000
VXLAN that

137
06:58.000 --> 07:04.600
Cisco developed called VXLAN group policy option or GPO because we're going to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

137
06:58.000 --> 07:04.600
Cisco developed called VXLAN group policy option or GPO because we're going to

138
07:04.600 --> 07:05.240
carry a

139
07:05.240 --> 07:11.380
little bit of extra information and spoiler alert this is going to be the

140
07:11.380 --> 07:12.600
scalable group

141
07:12.600 --> 07:16.960
tag or the SGT which we'll be talking about in the next video.

142
07:16.960 --> 07:23.620
We're also going to find that we maintain the QOS information we actually

143
07:23.620 --> 07:24.320
migrate QOS

144
07:24.320 --> 07:32.190
data from the inner header here and we place it into the outer header over here
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

144
07:24.320 --> 07:32.190
data from the inner header here and we place it into the outer header over here

145
07:32.190 --> 07:32.320
.

146
07:32.320 --> 07:37.830
That way our QOS tags and QOS policies get respected through the entire under

147
07:37.830 --> 07:38.440
lay.

148
07:38.440 --> 07:44.840
So the way VXLAN works is we're going to add a header right here in the middle

149
07:44.840 --> 07:45.280
and this

150
07:45.280 --> 07:48.040
is a 50 byte header.

151
07:48.040 --> 07:53.200
This header is going to contain some very important information.

152
07:53.200 --> 07:58.530
Most importantly it's going to carry our 24 bit VXLAN identifier which we call

153
07:58.530 --> 07:59.720
a virtual network

154
07:59.720 --> 08:04.210
identifier sometimes referred to as a VNID but usually especially in Cisco
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

154
07:59.720 --> 08:04.210
identifier sometimes referred to as a VNID but usually especially in Cisco

155
08:04.210 --> 08:05.200
documentation

156
08:05.200 --> 08:08.240
we're going to see it as a VNI.

157
08:08.240 --> 08:15.910
For bits this means we have 16.7 million different VXLAN identifiers that we

158
08:15.910 --> 08:17.240
can use so that's

159
08:17.240 --> 08:21.280
pretty cool and gives us plenty of options in SDA.

160
08:21.280 --> 08:26.320
In SDA we don't need nearly that number but VXLAN is primarily developed for

161
08:26.320 --> 08:26.920
data center

162
08:26.920 --> 08:31.860
applications we're applying it to SDA and in the data center 16 million is a
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

162
08:26.920 --> 08:31.860
applications we're applying it to SDA and in the data center 16 million is a

163
08:31.860 --> 08:32.560
great number

164
08:32.560 --> 08:37.600
for us to have especially for a service provider with lots of customers.

165
08:37.600 --> 08:43.280
Now importantly because we're adding 50 bytes and also importantly that there

166
08:43.280 --> 08:44.680
is no fragmentation

167
08:44.680 --> 08:51.070
supported by a VXLAN this means that our underlay must support at least 1550

168
08:51.070 --> 08:53.480
bytes, 50 additional

169
08:53.480 --> 08:55.360
bytes for Mtu.

170
08:55.360 --> 09:02.030
So we need to make sure that our underlay supports that Mtu and hopefully in an
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

170
08:55.360 --> 09:02.030
So we need to make sure that our underlay supports that Mtu and hopefully in an

171
09:02.030 --> 09:02.680
SDA environment

172
09:02.680 --> 09:07.100
because it's all our own equipment building connections out to our Xs layer

173
09:07.100 --> 09:07.840
switches this

174
09:07.840 --> 09:11.250
shouldn't be a problem but we definitely need to take it into account if we're

175
09:11.250 --> 09:11.720
building

176
09:11.720 --> 09:14.240
this out ourselves.

177
09:14.240 --> 09:18.890
So remember these layer three interfaces we said that this is a loop back

178
09:18.890 --> 09:19.760
interface and

179
09:19.760 --> 09:25.520
we're going to call this in the list world a routing locator or an RLock.

180
09:25.520 --> 09:30.210
Well VXLAN also has a term for this it is known as a virtual tunneling endpoint
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

180
09:25.520 --> 09:30.210
Well VXLAN also has a term for this it is known as a virtual tunneling endpoint

181
09:30.210 --> 09:31.920
or a VTEP

182
09:31.920 --> 09:35.400
so we're going to build these tunnels between VTEPs.

183
09:35.400 --> 09:39.200
Just understand that we're talking ultimately about the same thing here.

184
09:39.200 --> 09:43.190
We're talking about a layer three interface on these edge devices that are part

185
09:43.190 --> 09:43.640
of the

186
09:43.640 --> 09:48.270
underlay meaning that all of the underlay devices know how to reach it and from

187
09:48.270 --> 09:48.920
a VXLAN

188
09:48.920 --> 09:53.880
perspective we're going to build our tunnels from VTEP to VTEP.

189
09:53.880 --> 09:56.240
So let's go all the way back to our example.

190
09:56.240 --> 09:59.900
We know that we've got this packet that came in and now we're going to build

191
09:59.900 --> 10:00.520
this outer
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

191
09:59.900 --> 10:00.520
this outer

192
10:00.520 --> 10:06.160
header here in the tunnel that has a destination address of the remote VTEP.

193
10:06.160 --> 10:10.830
I then send that packet into the underlay and the underlay only ever sees that

194
10:10.830 --> 10:11.380
I'm trying

195
10:11.380 --> 10:13.640
to get to the remote edge device.

196
10:13.640 --> 10:19.520
So we forward this packet along the path and eventually it gets to the remote

197
10:19.520 --> 10:19.600
device.

198
10:19.600 --> 10:22.520
It decapsulates that packet.

199
10:22.520 --> 10:27.730
It looks at the underlying inner layer to frame and says okay now I see that

200
10:27.730 --> 10:28.680
this frame

201
10:28.680 --> 10:33.390
is destined for host B and again because it's layer three we're looking at a
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

201
10:28.680 --> 10:33.390
is destined for host B and again because it's layer three we're looking at a

202
10:33.390 --> 10:34.240
MAC address

203
10:34.240 --> 10:37.680
and I'm going to forward it down to the appropriate host.

204
10:37.680 --> 10:42.490
In this fashion because we preserve the layer to header information we have

205
10:42.490 --> 10:43.640
again stretched

206
10:43.640 --> 10:48.640
this subnet we have stretched this VLAN between our edge devices even though we

207
10:48.640 --> 10:49.640
are separated

208
10:49.640 --> 10:51.000
by a layer three underlay.

209
10:51.000 --> 11:01.000
[BLANK_AUDIO]