WEBVTT

1
00:00.000 --> 00:03.600
Well, this is a story that's as old as time.

2
00:03.600 --> 00:07.230
In fact, you've probably potentially heard me or somebody else tell this story,

3
00:07.230 --> 00:07.360
which

4
00:07.360 --> 00:13.240
is that Cisco, seeing a problem in the networking world, said, "Hey, we've got

5
00:13.240 --> 00:14.040
a great solution

6
00:14.040 --> 00:15.040
for this.

7
00:15.040 --> 00:17.240
We're going to create a solution for this."

8
00:17.240 --> 00:20.840
And then eventually the rest of the industry says, "Hey, we need that too."

9
00:20.840 --> 00:25.160
And they create a version that everybody can use, not just Cisco.

10
00:25.160 --> 00:30.440
And in most cases, the Cisco version kind of gets quietly retired or sunset.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

10
00:25.160 --> 00:30.440
And in most cases, the Cisco version kind of gets quietly retired or sunset.

11
00:30.440 --> 00:34.390
In other cases, sometimes Cisco keeps that technology alive alongside the

12
00:34.390 --> 00:35.800
industry standard.

13
00:35.800 --> 00:37.040
What am I talking about here?

14
00:37.040 --> 00:40.200
Well, what I'm talking about is the trunking world.

15
00:40.200 --> 00:43.720
We're all used to hearing about this 802.1Q trunking.

16
00:43.720 --> 00:49.840
And anytime we see this, 802.something, we're usually talking about the IEEE.

17
00:49.840 --> 00:52.520
The IEEE is a standards-based organization.

18
00:52.520 --> 00:56.980
They create standards and those standards can be used by anybody, whether it's

19
00:56.980 --> 00:57.400
Cisco

20
00:57.400 --> 00:59.800
or one of Cisco's competitors.

21
00:59.800 --> 01:04.570
Meanwhile, Cisco likes to create their own technologies that only usually they
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

21
00:59.800 --> 01:04.570
Meanwhile, Cisco likes to create their own technologies that only usually they

22
01:04.570 --> 01:06.000
can use.

23
01:06.000 --> 01:07.440
That's not always the case.

24
01:07.440 --> 01:10.240
Sometimes they do open it up for everybody else to use.

25
01:10.240 --> 01:13.820
But even in those cases, if you're Cisco's competitor, you really want to be

26
01:13.820 --> 01:14.960
using Cisco's

27
01:14.960 --> 01:15.960
stuff.

28
01:15.960 --> 01:19.730
Usually you want to use industry standard for the sake of interoperability, as

29
01:19.730 --> 01:20.240
well as

30
01:20.240 --> 01:24.040
just not giving credit to your direct competitor.

31
01:24.040 --> 01:30.240
So way back in the day, Cisco saw this problem that we had, which is eventually
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

31
01:24.040 --> 01:30.240
So way back in the day, Cisco saw this problem that we had, which is eventually

32
01:30.240 --> 01:30.960
solved by

33
01:30.960 --> 01:31.960
trunking.

34
01:31.960 --> 01:36.190
And we look at 802.1Q and say, oh, so that must be the solution, except there

35
01:36.190 --> 01:37.160
was a solution

36
01:37.160 --> 01:39.160
Cisco created first.

37
01:39.160 --> 01:40.780
So let's look at this problem.

38
01:40.780 --> 01:44.200
The problem is that we have now invented VLANs.

39
01:44.200 --> 01:47.400
And I've got two VLANs, VLANs 10 and 20.

40
01:47.400 --> 01:51.480
And I've got this other physical switch and some remote closet.

41
01:51.480 --> 01:55.900
And I want some of the hosts attached here to be able to talk to hosts in VLAN

42
01:55.900 --> 01:56.640
10 up

43
01:56.640 --> 01:57.640
here.

44
01:57.640 --> 02:00.640
And some of the hosts to be talking to VLAN 20 up here.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

44
01:57.640 --> 02:00.640
And some of the hosts to be talking to VLAN 20 up here.

45
02:00.640 --> 02:03.040
Why do my switches look like cats with whiskers?

46
02:03.040 --> 02:05.880
Then we'll either way, we'd say, okay, well, that's great.

47
02:05.880 --> 02:11.890
I want these hosts therefore to be in VLAN 10, these hosts over here to be in V

48
02:11.890 --> 02:12.800
LAN 20.

49
02:12.800 --> 02:14.720
And here lies the problem.

50
02:14.720 --> 02:18.040
How do I connect these two switches together?

51
02:18.040 --> 02:22.340
And so at first we'd just say, okay, well, I'll connect a connection here in V

52
02:22.340 --> 02:23.040
LAN 10 and

53
02:23.040 --> 02:25.400
a connection here in VLAN 20.

54
02:25.400 --> 02:26.840
And that works.

55
02:26.840 --> 02:31.760
That's perfectly fine until I have five or 10 VLANs.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

55
02:26.840 --> 02:31.760
That's perfectly fine until I have five or 10 VLANs.

56
02:31.760 --> 02:35.890
And all of a sudden I need to have as many connections between these switches

57
02:35.890 --> 02:36.400
as I have

58
02:36.400 --> 02:37.600
VLANs.

59
02:37.600 --> 02:40.240
And these switches only have 24 or 48 ports.

60
02:40.240 --> 02:44.040
If I have to use 10 of them to connect to other switches, then that's going to

61
02:44.040 --> 02:45.040
be problematic.

62
02:45.040 --> 02:47.880
We see that this does not scale.

63
02:47.880 --> 02:54.410
So the, again, solution was to create a way for us to connect these switches

64
02:54.410 --> 02:55.520
that allows

65
02:55.520 --> 02:59.520
one single connection to carry multiple VLANs.

66
02:59.520 --> 03:02.160
This is the trunk.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

66
02:59.520 --> 03:02.160
This is the trunk.

67
03:02.160 --> 03:06.810
And the idea is that I can send a layer two frame across this trunk and it's

68
03:06.810 --> 03:07.320
going to

69
03:07.320 --> 03:13.920
include a tag that lets the other side know which VLAN this packet belongs to.

70
03:13.920 --> 03:19.920
So I would include a tag for VLAN 10 and that way this receiving device knows

71
03:19.920 --> 03:20.640
to check

72
03:20.640 --> 03:25.920
the cam table in VLAN 10 here as well as potentially if it's a broadcast packet

73
03:25.920 --> 03:27.200
, I know which ports

74
03:27.200 --> 03:28.680
to send it out.

75
03:28.680 --> 03:30.080
So that's great and all.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

75
03:28.680 --> 03:30.080
So that's great and all.

76
03:30.080 --> 03:33.870
On paper this is looking good, but how do we decide the technical

77
03:33.870 --> 03:35.080
specifications of

78
03:35.080 --> 03:39.200
the trunk and what does this tag look like and so on and so forth.

79
03:39.200 --> 03:44.300
And so this led Cisco, not the industry, but Cisco to create a technology known

80
03:44.300 --> 03:45.000
as Inner,

81
03:45.000 --> 03:48.360
Switch, Link, or ISL.

82
03:48.360 --> 03:51.120
This was the original trunking standard.

83
03:51.120 --> 03:53.200
Well, I shouldn't use the word standard.

84
03:53.200 --> 03:55.400
It was the original trunking technology.

85
03:55.400 --> 04:01.080
It was created by Cisco and as a result it was only available on Cisco devices.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

85
03:55.400 --> 04:01.080
It was created by Cisco and as a result it was only available on Cisco devices.

86
04:01.080 --> 04:04.900
Now it didn't take the industry long to say, okay, well we need that technology

87
04:04.900 --> 04:05.320
but we

88
04:05.320 --> 04:09.600
need everybody to be able to use it, not just Cisco.

89
04:09.600 --> 04:15.600
And so that's where the IEEE created 802.1Q trunking and said, okay, we like

90
04:15.600 --> 04:16.400
your ideas

91
04:16.400 --> 04:19.120
but we're going to make them a little bit better.

92
04:19.120 --> 04:24.680
So let's just have a very brief conversation about what ISL was.

93
04:24.680 --> 04:27.680
Because ISL is kind of an interesting protocol.

94
04:27.680 --> 04:31.890
Once again, it was Cisco proprietary, we know that it was only available on
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

94
04:27.680 --> 04:31.890
Once again, it was Cisco proprietary, we know that it was only available on

95
04:31.890 --> 04:33.320
Cisco switches.

96
04:33.320 --> 04:34.760
But here's the fascinating thing.

97
04:34.760 --> 04:42.380
It used true encapsulation, meaning that we were taking the Ethernet frame with

98
04:42.380 --> 04:43.320
its header

99
04:43.320 --> 04:48.960
and with its payload and with its CRC and we were encapsulating it in an ISL

100
04:48.960 --> 04:50.240
header and

101
04:50.240 --> 04:53.160
an ISL CRC.

102
04:53.160 --> 04:59.560
In other words, we were almost treating this as if it was a tunnel interface.

103
04:59.560 --> 05:05.760
And so the ISL header was actually 26 bytes and the CRC was an additional 4
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

103
04:59.560 --> 05:05.760
And so the ISL header was actually 26 bytes and the CRC was an additional 4

104
05:05.760 --> 05:06.240
bytes.

105
05:06.240 --> 05:11.280
So we're adding 30 bytes to every single frame and sending it out.

106
05:11.280 --> 05:14.000
That's a pretty large overhead.

107
05:14.000 --> 05:19.140
But at the same time we actually did get one benefit compared to 802.1Q which

108
05:19.140 --> 05:19.640
is that

109
05:19.640 --> 05:24.960
we had 15 bits for the VLAN identifier.

110
05:24.960 --> 05:30.160
That's a lot more VLAN IDs than the 12 bits that we get from 802.1Q.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

110
05:24.960 --> 05:30.160
That's a lot more VLAN IDs than the 12 bits that we get from 802.1Q.

111
05:30.160 --> 05:35.270
In fact, it's eight times the number of VLAN IDs that would have been available

112
05:35.270 --> 05:35.800
using

113
05:35.800 --> 05:36.800
ISL.

114
05:36.800 --> 05:41.040
Furthermore, there was no such thing as a native VLAN.

115
05:41.040 --> 05:45.320
So that concept didn't exist with ISL.

116
05:45.320 --> 05:51.280
And the most important part about ISL is that Cisco really no longer supports

117
05:51.280 --> 05:52.040
this.

118
05:52.040 --> 05:57.910
So if we try to configure ISL on modern hardware like the Catalyst9 case, we're

119
05:57.910 --> 05:58.720
going to find

120
05:58.720 --> 06:00.720
that it's not available.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

120
05:58.720 --> 06:00.720
that it's not available.

121
06:00.720 --> 06:04.080
Although I will say that ISL was supported for a very long time.

122
06:04.080 --> 06:08.740
If you have some maybe some Cisco devices that are 10 to 15 years old at this

123
06:08.740 --> 06:09.360
point that

124
06:09.360 --> 06:14.440
probably still support ISL, then you could configure it if you wanted to see it

125
06:14.440 --> 06:15.280
in action.

126
06:15.280 --> 06:18.430
So the industry then said, all right, this is great and all, but we're going to

127
06:18.430 --> 06:18.880
create

128
06:18.880 --> 06:23.160
our own version and we're not going to use encapsulation.

129
06:23.160 --> 06:27.230
We're going to use this concept of a shim header or it's probably not even the

130
06:27.230 --> 06:27.640
right

131
06:27.640 --> 06:34.660
way of saying it in this case because we're going to modify the Ethernet header
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

131
06:27.640 --> 06:34.660
way of saying it in this case because we're going to modify the Ethernet header

132
06:34.660 --> 06:34.720
.

133
06:34.720 --> 06:38.840
When we modify the Ethernet header, we're truly going to insert into the middle

134
06:38.840 --> 06:39.280
of it.

135
06:39.280 --> 06:45.480
So here's our frame and here's our payload and here's our Ethernet header and

136
06:45.480 --> 06:46.160
the CRC

137
06:46.160 --> 06:47.960
at the end.

138
06:47.960 --> 06:55.820
Well we're going to insert four bytes that's going to allow us to carry a VLAN

139
06:55.820 --> 06:56.560
ID.

140
06:56.560 --> 07:02.720
Now this four bytes breaks down such that two of these bytes are really just a
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

140
06:56.560 --> 07:02.720
Now this four bytes breaks down such that two of these bytes are really just a

141
07:02.720 --> 07:04.120
identifier.

142
07:04.120 --> 07:08.000
It's hex zero, hex 8100.

143
07:08.000 --> 07:11.000
And so it seems like a lot of wasted space to just be sitting there with the

144
07:11.000 --> 07:11.440
first two

145
07:11.440 --> 07:13.280
bytes over here.

146
07:13.280 --> 07:15.920
But then when we get over to the next two bytes, this is where things get a

147
07:15.920 --> 07:16.440
little more

148
07:16.440 --> 07:17.640
interesting.

149
07:17.640 --> 07:23.100
Specifically, we have 12 bits that are the VLAN identifier and an extra four

150
07:23.100 --> 07:23.840
bits that

151
07:23.840 --> 07:26.240
we use for quality of service.

152
07:26.240 --> 07:32.440
So VLAN ID here and over here, this is where that class of service gets
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

152
07:26.240 --> 07:32.440
So VLAN ID here and over here, this is where that class of service gets

153
07:32.440 --> 07:33.720
leverage.

154
07:33.720 --> 07:36.840
Now we recall class of service is only three bits.

155
07:36.840 --> 07:42.400
And so we actually get three for the class of service, but then we get another

156
07:42.400 --> 07:43.040
one and

157
07:43.040 --> 07:48.280
this is used for something called the drop eligible indicator, the DEI.

158
07:48.280 --> 07:52.720
But either way, this is all part of quality of service.

159
07:52.720 --> 07:57.920
So we may recall during our quality of service conversations that if I don't

160
07:57.920 --> 07:58.920
have a trunk,

161
07:58.920 --> 08:00.880
then I can't carry COS bits.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

161
07:58.920 --> 08:00.880
then I can't carry COS bits.

162
08:00.880 --> 08:04.910
And the reason for that is simply if I'm sending out an Ethernet frame on an

163
08:04.910 --> 08:05.840
access port, I

164
08:05.840 --> 08:09.080
don't get any of these bits whatsoever.

165
08:09.080 --> 08:13.840
I don't get the VLAN ID, but I also don't get the class of service bits.

166
08:13.840 --> 08:17.780
And so that's why we have to make sure that we use trunks in order to carry

167
08:17.780 --> 08:18.800
class of service

168
08:18.800 --> 08:23.040
if we're going to rely on it for quality of service.

169
08:23.040 --> 08:28.560
Now 802.1Q also introduced the concept of the native VLAN.

170
08:28.560 --> 08:34.160
So the idea of the native VLAN is that we don't have to tag it.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

170
08:28.560 --> 08:34.160
So the idea of the native VLAN is that we don't have to tag it.

171
08:34.160 --> 08:36.240
It is untagged.

172
08:36.240 --> 08:41.410
The idea here was that it was considered a lot of overhead, especially at the

173
08:41.410 --> 08:42.280
time, to carry

174
08:42.280 --> 08:44.920
an extra four bytes per frame.

175
08:44.920 --> 08:47.040
Is it that much percentage wise?

176
08:47.040 --> 08:48.800
It's really not that critical.

177
08:48.800 --> 08:52.400
And these days we don't really care that much about an extra four bytes.

178
08:52.400 --> 08:55.910
But at the time that was the idea was, hey, we're kind of being a little bit

179
08:55.910 --> 08:56.720
clever here.

180
08:56.720 --> 09:01.080
We're getting rid of the overhead for maybe the VLAN that has the most traffic.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

180
08:56.720 --> 09:01.080
We're getting rid of the overhead for maybe the VLAN that has the most traffic.

181
09:01.080 --> 09:03.760
We can declare it the native VLAN on a trunk.

182
09:03.760 --> 09:08.080
We only get a single native VLAN because any untagged traffic will be assumed

183
09:08.080 --> 09:08.880
to be part

184
09:08.880 --> 09:11.440
of the native VLAN.

185
09:11.440 --> 09:16.710
Now these days for number one, reasons with COS, we'd say, hey, we do want

186
09:16.710 --> 09:18.040
class of service

187
09:18.040 --> 09:19.480
even on the native VLAN.

188
09:19.480 --> 09:24.160
So we want to carry that tag even in the cases of native VLANs.

189
09:24.160 --> 09:28.910
But from a security perspective, we generally would rather not use native VLANs

190
09:28.910 --> 09:29.600
either.

191
09:29.600 --> 09:33.730
So in modern networks, we'd really rather disable the native VLAN and we'll
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

191
09:29.600 --> 09:33.730
So in modern networks, we'd really rather disable the native VLAN and we'll

192
09:33.730 --> 09:34.320
talk more

193
09:34.320 --> 09:36.200
about that coming up.

194
09:36.200 --> 09:42.040
But either way, 802.1Q did introduce the concept of the native VLAN as well.

195
09:42.040 --> 09:46.240
Now one last consideration in all of this is we're talking about bits and bytes

196
09:46.240 --> 09:46.520
.

197
09:46.520 --> 09:49.120
And we might want to ask, hey, what about MTU?

198
09:49.120 --> 09:51.080
Do we need to worry about this?

199
09:51.080 --> 09:56.710
We may recall from MTU-based conversations that layer two MTU is usually set at

200
09:56.710 --> 09:57.840
1500

201
09:57.840 --> 09:58.840
bytes.

202
09:58.840 --> 10:00.880
That's certainly the default.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

202
09:58.840 --> 10:00.880
That's certainly the default.

203
10:00.880 --> 10:07.000
And furthermore, layer two, ethernet, it doesn't support fragmentation.

204
10:07.000 --> 10:11.960
And as a result, if we exceed the MTU, the packet is going to get dropped.

205
10:11.960 --> 10:16.460
We can't just fragment it and send it on like we can if we break layer three MT

206
10:16.460 --> 10:18.120
U, for example.

207
10:18.120 --> 10:20.440
So what does trunking do for us?

208
10:20.440 --> 10:25.920
I mean, we talked originally about adding 30 bytes for ISL, but even with 802.1

209
10:25.920 --> 10:26.200
Q, we're

210
10:26.200 --> 10:28.360
adding an extra four bytes.

211
10:28.360 --> 10:32.480
Do we need to worry about changing MTU to 1504?
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

211
10:28.360 --> 10:32.480
Do we need to worry about changing MTU to 1504?

212
10:32.480 --> 10:40.100
And the answer is actually no, because layer two MTU is only going to map to

213
10:40.100 --> 10:41.840
the payload.

214
10:41.840 --> 10:43.280
We're talking about 1500 bytes.

215
10:43.280 --> 10:49.010
We're talking about in here 1500 bytes, which means that neither the ethernet

216
10:49.010 --> 10:49.800
header nor

217
10:49.800 --> 10:54.200
the CRC count towards that 1500 bytes.

218
10:54.200 --> 10:58.370
That works out really well for us because if the ethernet header lacks the VLAN

219
10:58.370 --> 10:58.760
ID and

220
10:58.760 --> 11:04.520
lacks the 802.1Q header, then fine, you know, it's not part of the MTU.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

220
10:58.760 --> 11:04.520
lacks the 802.1Q header, then fine, you know, it's not part of the MTU.

221
11:04.520 --> 11:08.730
But even if it does include the header, it still doesn't include or it is not

222
11:08.730 --> 11:09.320
counted

223
11:09.320 --> 11:10.920
towards the MTU.

224
11:10.920 --> 11:14.770
Now we might need to worry about it if this whole thing ends up getting encaps

225
11:14.770 --> 11:15.320
ulated,

226
11:15.320 --> 11:19.400
like we saw with VXLAN when I encapsulate this into VXLAN.

227
11:19.400 --> 11:24.600
Now all of a sudden it does matter whether this inner header had those extra,

228
11:24.600 --> 11:26.020
is it 14

229
11:26.020 --> 11:27.360
bytes or is it 18 bytes?

230
11:27.360 --> 11:29.840
Are we talking about the extra four or not?

231
11:29.840 --> 11:32.120
At that point, we might need to worry about it.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

231
11:29.840 --> 11:32.120
At that point, we might need to worry about it.

232
11:32.120 --> 11:36.670
However, just in a standard layer two network, we fortunately don't have to

233
11:36.670 --> 11:38.000
worry about MTU.

234
11:38.000 --> 11:43.080
That problem isn't even a problem because the MTU only applies to the payload.

235
11:43.080 --> 11:51.740
[BLANK_AUDIO]