WEBVTT

1
00:00.000 --> 00:05.940
The hierarchical network model covers the entire network from every one of our

2
00:05.940 --> 00:06.280
sites

3
00:06.280 --> 00:11.100
where our users are to our data centers to our remote locations to the internet

4
00:11.100 --> 00:11.400
block

5
00:11.400 --> 00:13.640
and everything in between.

6
00:13.640 --> 00:17.240
And so what we want to do here now is to zoom in a little bit.

7
00:17.240 --> 00:20.360
The hierarchical network model great for a big picture.

8
00:20.360 --> 00:24.650
But now we need to zoom in and look at those three key layers that we often

9
00:24.650 --> 00:25.400
talk about

10
00:25.400 --> 00:29.280
the core layer, the distribution layer, and the access layer.

11
00:29.280 --> 00:33.380
In a single site, we can expect to have a distribution layer and an access
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

11
00:29.280 --> 00:33.380
In a single site, we can expect to have a distribution layer and an access

12
00:33.380 --> 00:33.880
layer.

13
00:33.880 --> 00:37.230
And if we have lots of sites, like we talked about in the last skill, then we

14
00:37.230 --> 00:37.740
'll have lots

15
00:37.740 --> 00:40.440
of distribution and lots of access layers.

16
00:40.440 --> 00:43.640
But we're still going to have a single core layer throughout all of that.

17
00:43.640 --> 00:48.370
So if we have a campus environment with 15 buildings, we might have 15

18
00:48.370 --> 00:49.200
distribution

19
00:49.200 --> 00:51.840
blocks, but only a single core block.

20
00:51.840 --> 00:55.730
And yes, every now and again, we'll use block and layer interchangeably when we

21
00:55.730 --> 00:56.520
're talking

22
00:56.520 --> 00:58.640
about the campus model.

23
00:58.640 --> 01:03.800
So let's go ahead and drill in first of all to this core block.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

23
00:58.640 --> 01:03.800
So let's go ahead and drill in first of all to this core block.

24
01:03.800 --> 01:08.580
So when we're talking about the core, as we might imagine, this is arguably the

25
01:08.580 --> 01:10.040
most critical

26
01:10.040 --> 01:12.880
component in the entire network.

27
01:12.880 --> 01:18.720
This is that the center or the hub of the hierarchical network model.

28
01:18.720 --> 01:24.600
So it's going to connect to all other network blocks.

29
01:24.600 --> 01:26.440
This makes it very critical.

30
01:26.440 --> 01:31.200
If the core goes down, then all of the other blocks are going to be unable to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

30
01:26.440 --> 01:31.200
If the core goes down, then all of the other blocks are going to be unable to

31
01:31.200 --> 01:32.160
communicate

32
01:32.160 --> 01:34.200
with one another.

33
01:34.200 --> 01:39.630
And so we need to make sure that the core is highly resilient and highly robust

34
01:39.630 --> 01:39.960
.

35
01:39.960 --> 01:42.080
Ultimately, it needs to stay online.

36
01:42.080 --> 01:46.640
So uptime is going to be a big conversation when it comes to our core.

37
01:46.640 --> 01:52.510
But because of how critical our core network is, we might expect that the core

38
01:52.510 --> 01:53.200
is going

39
01:53.200 --> 01:56.440
to be very high in features.

40
01:56.440 --> 02:01.440
We probably want a very expensive switch with lots of features, spare no
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

40
01:56.440 --> 02:01.440
We probably want a very expensive switch with lots of features, spare no

41
02:01.440 --> 02:02.460
expense for the

42
02:02.460 --> 02:04.480
core switch, right?

43
02:04.480 --> 02:07.560
Except we are going to find that this is not the case.

44
02:07.560 --> 02:11.800
We don't actually care about features when it comes to the core.

45
02:11.800 --> 02:17.330
And when we're talking about features, we're talking about all kinds of maybe

46
02:17.330 --> 02:18.000
special

47
02:18.000 --> 02:21.640
capabilities that a lot of edge switches might have.

48
02:21.640 --> 02:25.360
And that's because when we're talking about the core of the network, we don't

49
02:25.360 --> 02:26.600
care necessarily

50
02:26.600 --> 02:30.080
about being able to power up phones, for example.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

50
02:26.600 --> 02:30.080
about being able to power up phones, for example.

51
02:30.080 --> 02:34.080
I mean, do we need power over ethernet on our core switch?

52
02:34.080 --> 02:35.720
And we'd probably say, no, you know what?

53
02:35.720 --> 02:39.000
We don't actually need power over ethernet at the core.

54
02:39.000 --> 02:43.320
We shouldn't be connecting phones or access points to the core switch.

55
02:43.320 --> 02:47.130
And so these are the types of features that we can probably do without when it

56
02:47.130 --> 02:47.520
comes

57
02:47.520 --> 02:50.200
to speccing out a core switch that we want to deploy.

58
02:50.200 --> 02:56.560
So aside from up time, what do we care most about when it comes to the core?

59
02:56.560 --> 03:01.160
Well, first of all, we're going to care about our interconnections.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

59
02:56.560 --> 03:01.160
Well, first of all, we're going to care about our interconnections.

60
03:01.160 --> 03:05.440
We just said that we're going to connect all of the other network blocks.

61
03:05.440 --> 03:10.060
And so that's probably going to require some amount of concern around how we're

62
03:10.060 --> 03:10.440
going

63
03:10.440 --> 03:14.750
to connect to all of the other network switches that are out there that need to

64
03:14.750 --> 03:15.560
form connections

65
03:15.560 --> 03:17.120
to the core.

66
03:17.120 --> 03:22.440
The other thing that we're going to care heavily about is how fast we can

67
03:22.440 --> 03:23.580
switch among those

68
03:23.580 --> 03:24.740
blocks.

69
03:24.740 --> 03:29.520
So this is going to involve fast switching, but not just fast switching in

70
03:29.520 --> 03:31.120
general, specifically
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

70
03:29.520 --> 03:31.120
general, specifically

71
03:31.120 --> 03:35.080
fast layer three switching.

72
03:35.080 --> 03:39.980
Now we talk about layer three, sometimes our focus is on the routing concept.

73
03:39.980 --> 03:45.180
But when we're talking about a switch, we can very quickly switch packets via

74
03:45.180 --> 03:45.920
hardware

75
03:45.920 --> 03:46.920
mechanisms.

76
03:46.920 --> 03:50.140
That's what we're talking about with fast layer three switching.

77
03:50.140 --> 03:54.330
Having all of the routes already updated, hopefully in a stable environment,

78
03:54.330 --> 03:55.000
will allow us

79
03:55.000 --> 04:00.510
to bring a packet in and very quickly, very, very quickly from a time
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

79
03:55.000 --> 04:00.510
to bring a packet in and very quickly, very, very quickly from a time

80
04:00.510 --> 04:01.920
perspective.

81
04:01.920 --> 04:02.920
That's a clock in there.

82
04:02.920 --> 04:07.410
If you couldn't tell with all the hour and then a hand, little, okay, yeah, it

83
04:07.410 --> 04:08.440
's a clock.

84
04:08.440 --> 04:13.300
Either way, the packet comes in, went to very quickly, switch this out from the

85
04:13.300 --> 04:14.000
incoming

86
04:14.000 --> 04:20.440
interface or ingress to the outgoing interface or the egress.

87
04:20.440 --> 04:22.880
So let's drill into these in a little bit more detail.

88
04:22.880 --> 04:24.400
Let's start with the interconnections.

89
04:24.400 --> 04:27.650
Now, again, the core is going to connect to all of our other blocks, but when

90
04:27.650 --> 04:28.400
we think about

91
04:28.400 --> 04:32.870
it from a block to block perspective, it's easy to see that, yeah, we just have
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

91
04:28.400 --> 04:32.870
it from a block to block perspective, it's easy to see that, yeah, we just have

92
04:32.870 --> 04:33.480
a single

93
04:33.480 --> 04:35.600
connection here.

94
04:35.600 --> 04:39.330
That's great from a logical perspective, but not so great from a physical

95
04:39.330 --> 04:40.240
perspective.

96
04:40.240 --> 04:44.930
So instead, what we do is we have two switches here at the core and let's say

97
04:44.930 --> 04:45.720
we're connecting

98
04:45.720 --> 04:47.480
to a distribution layer.

99
04:47.480 --> 04:50.920
So we're going to have a pair of switches over here at the distribution layer

100
04:50.920 --> 04:51.480
and we want

101
04:51.480 --> 04:53.440
to connect these all together.

102
04:53.440 --> 05:00.160
So what we do is we connect through that line that we drew and maybe we create
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

102
04:53.440 --> 05:00.160
So what we do is we connect through that line that we drew and maybe we create

103
05:00.160 --> 05:00.800
a full

104
05:00.800 --> 05:02.840
mesh of connectivity.

105
05:02.840 --> 05:06.240
Now depending on the fiber connections, we might be limited.

106
05:06.240 --> 05:10.110
We might only be able to do a pair of these connections, get rid of that line

107
05:10.110 --> 05:11.440
in the middle.

108
05:11.440 --> 05:14.800
And so now we just have two connections going between the two, but we do

109
05:14.800 --> 05:15.720
absolutely want

110
05:15.720 --> 05:17.920
to be redundant here.

111
05:17.920 --> 05:23.300
And so what we care a lot about here is making sure that we have the proper

112
05:23.300 --> 05:24.400
port count.

113
05:24.400 --> 05:27.300
Because it's not just this one distribution block, we might have several

114
05:27.300 --> 05:28.880
distribution blocks.

115
05:28.880 --> 05:33.060
And so now we need to make sure that we have two or maybe even four connections
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

115
05:28.880 --> 05:33.060
And so now we need to make sure that we have two or maybe even four connections

116
05:33.060 --> 05:33.320
going

117
05:33.320 --> 05:34.480
out to each one of these.

118
05:34.480 --> 05:37.940
And as we can see, just from this basic drawing, we're going to run out of

119
05:37.940 --> 05:39.440
ports very quickly

120
05:39.440 --> 05:41.880
if we under spec our switches.

121
05:41.880 --> 05:47.760
Now the other thing to consider is the port type.

122
05:47.760 --> 05:51.840
Now we might have a lot of distribution switches if we're on a campus.

123
05:51.840 --> 05:55.480
And at that point, we have to care about is this multi-mode fiber?

124
05:55.480 --> 05:57.640
Is it single mode fiber?

125
05:57.640 --> 06:00.140
For the most part, if we're going outside of our building, it's probably going
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

125
05:57.640 --> 06:00.140
For the most part, if we're going outside of our building, it's probably going

126
06:00.140 --> 06:00.720
to be single

127
06:00.720 --> 06:02.400
mode fiber.

128
06:02.400 --> 06:06.020
But in general, it doesn't actually matter a whole lot more speaking out our

129
06:06.020 --> 06:06.880
switches,

130
06:06.880 --> 06:11.370
because these are going to be the optics or the transceivers that we install

131
06:11.370 --> 06:12.360
into a modular

132
06:12.360 --> 06:13.840
switch.

133
06:13.840 --> 06:18.800
What matters most is do we have enough SFP slots?

134
06:18.800 --> 06:22.880
And for that matter, do we have enough Q SFP slots?

135
06:22.880 --> 06:29.400
Now at the time of this video, we're talking about usually SFP 28 slots and Q

136
06:29.400 --> 06:31.240
SFP 28 slots,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

136
06:29.400 --> 06:31.240
SFP 28 slots,

137
06:31.240 --> 06:35.840
and we are already seeing Q SFP and SFP 56 slots coming out.

138
06:35.840 --> 06:39.400
And essentially what that translates into is the speed.

139
06:39.400 --> 06:45.440
So do we need our 10 and our 25 and our 50 gig ports?

140
06:45.440 --> 06:48.360
And this would be the SFP form factor.

141
06:48.360 --> 06:54.160
Or do we want to go with 40 gig and 100 and 200 and beyond?

142
06:54.160 --> 06:57.680
Well at that point, we need the Q SFP form factor.

143
06:57.680 --> 07:02.220
So back in the day, a long time ago, we had SFP plus and Q SFP plus in this map
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

143
06:57.680 --> 07:02.220
So back in the day, a long time ago, we had SFP plus and Q SFP plus in this map

144
07:02.220 --> 07:03.160
to 10 gig

145
07:03.160 --> 07:04.880
and 40 gig respectively.

146
07:04.880 --> 07:07.160
But we'll pass those days.

147
07:07.160 --> 07:12.560
We can use these same form factors to gear up and have again up to 50 gig on a

148
07:12.560 --> 07:13.800
single SFP

149
07:13.800 --> 07:14.800
slot.

150
07:14.800 --> 07:17.040
But again, that's not SFP plus anymore.

151
07:17.040 --> 07:22.400
That would be our SFP 56 and our Q SFP 56.

152
07:22.400 --> 07:27.780
And for that matter, we might even see Q SFP DDs in here and so on and so forth

153
07:27.780 --> 07:27.880
.

154
07:27.880 --> 07:31.590
So we have a lot of different port types and between making sure we have the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

154
07:27.880 --> 07:31.590
So we have a lot of different port types and between making sure we have the

155
07:31.590 --> 07:32.560
right types

156
07:32.560 --> 07:34.320
and the right port count.

157
07:34.320 --> 07:39.860
That's going to be a big part of our conversation when we're speccing out a

158
07:39.860 --> 07:41.080
core switch.

159
07:41.080 --> 07:45.170
Now I've been in various roles in the industry throughout my entire career, a

160
07:45.170 --> 07:46.440
significant part

161
07:46.440 --> 07:49.800
of my career was spent doing network designs.

162
07:49.800 --> 07:54.170
And so anytime we had a network core or even if it was a collapsed core type of

163
07:54.170 --> 07:55.160
environment,

164
07:55.160 --> 08:00.550
but either way, if we were speccing out core switches, this is primarily what
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

164
07:55.160 --> 08:00.550
but either way, if we were speccing out core switches, this is primarily what

165
08:00.550 --> 08:01.200
we cared

166
08:01.200 --> 08:02.200
about.

167
08:02.200 --> 08:06.480
We wanted to make sure that we had a switch that had enough ports.

168
08:06.480 --> 08:09.610
And again, it might be a little bit of a surprise for somebody just first

169
08:09.610 --> 08:10.720
learning about network

170
08:10.720 --> 08:14.240
designs like, well, the core switch, we really just care about port count.

171
08:14.240 --> 08:19.030
We don't care about, again, all these features and capabilities and all of that

172
08:19.030 --> 08:19.320
.

173
08:19.320 --> 08:23.160
And unless we're talking about how I can connect to my other network blocks or

174
08:23.160 --> 08:23.680
unless we're

175
08:23.680 --> 08:28.460
talking about how fast we can switch packets, then for the most part, no, we're

176
08:28.460 --> 08:29.200
not worried

177
08:29.200 --> 08:31.520
as much about those other features.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

177
08:29.200 --> 08:31.520
as much about those other features.

178
08:31.520 --> 08:35.880
We just need to make sure that number one, we have enough ports for today and

179
08:35.880 --> 08:36.200
number

180
08:36.200 --> 08:39.840
two, we have enough ports for future growth.

181
08:39.840 --> 08:42.800
And it's not just a matter of having enough SFP ports.

182
08:42.800 --> 08:47.640
What if one day I want to migrate and have 200 gig on these interfaces?

183
08:47.640 --> 08:50.240
At that point, I couldn't do that on SFP anymore.

184
08:50.240 --> 08:52.200
I would need QSFP to do it.

185
08:52.200 --> 08:55.920
And so lots of conversations, potentially around the different options.

186
08:55.920 --> 08:59.760
We could look at modular chassis switches to future proofs as well.

187
08:59.760 --> 09:01.080
Lots of things there.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

187
08:59.760 --> 09:01.080
Lots of things there.

188
09:01.080 --> 09:06.410
The key takeaway to this conversation up to this point is that we're really

189
09:06.410 --> 09:07.320
looking at

190
09:07.320 --> 09:11.970
here as far as the core is concerned is carrying greatly about the port type

191
09:11.970 --> 09:12.720
and the port

192
09:12.720 --> 09:13.720
count.

193
09:13.720 --> 09:17.790
Now, I did mention there that there is something else we care about, which is

194
09:17.790 --> 09:18.600
right here, our

195
09:18.600 --> 09:20.520
Fast Layer 3 switching.

196
09:20.520 --> 09:25.840
We can't just grab any switch that has these ports and call it a core switch.

197
09:25.840 --> 09:31.650
Yes, that's an important step, but we have to have the next step, which is to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

197
09:25.840 --> 09:31.650
Yes, that's an important step, but we have to have the next step, which is to

198
09:31.650 --> 09:32.640
zero in on

199
09:32.640 --> 09:34.120
performance.

200
09:34.120 --> 09:38.980
Now, performance can be measured in a lot of different ways when it comes to

201
09:38.980 --> 09:39.800
different

202
09:39.800 --> 09:41.520
switch hardware types.

203
09:41.520 --> 09:46.610
So we need to really take a look at things from a data plane perspective

204
09:46.610 --> 09:47.840
because that's

205
09:47.840 --> 09:51.080
the switching part.

206
09:51.080 --> 09:53.200
And this can be broken up into two facets.

207
09:53.200 --> 09:59.410
First of all, we want to make sure we have what's known as non-blocking back

208
09:59.410 --> 09:59.720
planes.

209
09:59.720 --> 10:02.840
And this ties to bandwidth.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

209
09:59.720 --> 10:02.840
And this ties to bandwidth.

210
10:02.840 --> 10:08.000
So we just said that we might want 200 gig, for example, on a switch.

211
10:08.000 --> 10:12.940
So let's say that I have a switch here and I have a 200 gig port on this side

212
10:12.940 --> 10:14.040
and a 200

213
10:14.040 --> 10:17.160
port gig port on this other side.

214
10:17.160 --> 10:24.700
So what if I am sending in 200 gig of traffic and that is getting sent out over

215
10:24.700 --> 10:25.600
here at the

216
10:25.600 --> 10:30.480
same time that 200 gig traffic is getting sent back?
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

216
10:25.600 --> 10:30.480
same time that 200 gig traffic is getting sent back?

217
10:30.480 --> 10:37.050
Well, that is a total of 400 gig of throughput that's happening here on this

218
10:37.050 --> 10:37.980
switch.

219
10:37.980 --> 10:43.990
And when we drill into switch architecture, there is a back plane that is

220
10:43.990 --> 10:45.220
handling all of

221
10:45.220 --> 10:47.100
that traffic for us.

222
10:47.100 --> 10:50.820
So the question is, can this back plane handle 400 gig?

223
10:50.820 --> 10:54.290
And for that matter, most back planes today could handle at least that much

224
10:54.290 --> 10:54.940
traffic.

225
10:54.940 --> 10:58.980
But what if I have a bunch more 200 gig ports?

226
10:58.980 --> 11:03.180
Well at this point, we might start to hit a limit to the back plane.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

226
10:58.980 --> 11:03.180
Well at this point, we might start to hit a limit to the back plane.

227
11:03.180 --> 11:07.730
And so if we can have a non-blocking back plane, what that's saying is if every

228
11:07.730 --> 11:09.540
port is firing

229
11:09.540 --> 11:14.970
inbound and outbound traffic at the max data rate that the back plane won't be

230
11:14.970 --> 11:16.220
overrun.

231
11:16.220 --> 11:20.750
And so this basically is saying that we're not going to use any over

232
11:20.750 --> 11:22.060
subscription on the

233
11:22.060 --> 11:24.820
back plane itself.

234
11:24.820 --> 11:28.880
This is an important concept when it comes to our core switches because we need

235
11:28.880 --> 11:29.260
to make

236
11:29.260 --> 11:34.450
sure that once again, we can do this fast layer 3 switching to bring traffic in
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

236
11:29.260 --> 11:34.450
sure that once again, we can do this fast layer 3 switching to bring traffic in

237
11:34.450 --> 11:35.540
from one network

238
11:35.540 --> 11:38.180
block and forward it out to the next network block.

239
11:38.180 --> 11:42.020
The entire purpose of the core is to perform these interconnections and then

240
11:42.020 --> 11:42.820
switch traffic

241
11:42.820 --> 11:44.100
between them.

242
11:44.100 --> 11:46.300
And so that's the first thing that we need to do.

243
11:46.300 --> 11:50.350
Number one, we need to make sure that as much as possible, we're in a non-block

244
11:50.350 --> 11:51.540
ing state,

245
11:51.540 --> 11:55.140
or at a minimum that the back plane can handle the amount of bandwidth that we

246
11:55.140 --> 11:55.740
expect to be

247
11:55.740 --> 11:57.580
throwing at it.

248
11:57.580 --> 12:02.220
But there is a second component to this and this has to do with the number of
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

248
11:57.580 --> 12:02.220
But there is a second component to this and this has to do with the number of

249
12:02.220 --> 12:02.900
packets that

250
12:02.900 --> 12:05.780
can be processed per second.

251
12:05.780 --> 12:12.060
So packets per second that the switch can process.

252
12:12.060 --> 12:15.900
This is something that can get overlooked when we're talking about speccing out

253
12:15.900 --> 12:16.420
a core

254
12:16.420 --> 12:17.420
switch.

255
12:17.420 --> 12:21.500
And the reason for that is because we tend to focus on bandwidth.

256
12:21.500 --> 12:23.300
And I'm as guilty of that as anybody.

257
12:23.300 --> 12:28.430
I mean, it's really fun to talk about 50 gig and 200 gig and even 408, 100 gig

258
12:28.430 --> 12:29.140
pipes and

259
12:29.140 --> 12:33.620
all of these different amounts of throughput that we might be throwing at our
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

259
12:29.140 --> 12:33.620
all of these different amounts of throughput that we might be throwing at our

260
12:33.620 --> 12:34.540
core switch.

261
12:34.540 --> 12:37.820
That is really easy to grasp and easy to expect.

262
12:37.820 --> 12:41.380
We know what a 200 gig a bit per second pipe looks like.

263
12:41.380 --> 12:46.340
The challenge is how many packets will we be sending in there?

264
12:46.340 --> 12:52.340
Because if we're sending 1500 byte packets at 200 gig.

265
12:52.340 --> 12:57.740
Well that's a whole lot fewer packets than if we're sending 100 byte packets at

266
12:57.740 --> 12:59.860
200 gig.

267
12:59.860 --> 13:02.020
This is a very low packet count.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

267
12:59.860 --> 13:02.020
This is a very low packet count.

268
13:02.020 --> 13:04.140
This is a very high packet count.

269
13:04.140 --> 13:11.060
There's going to be 15 times the number of packets being sent if they are only

270
13:11.060 --> 13:11.820
100 bytes

271
13:11.820 --> 13:14.940
in size and we still have the same bandwidth.

272
13:14.940 --> 13:19.480
So the amount of packets that can be processed per second is a spec on every

273
13:19.480 --> 13:20.660
network switch.

274
13:20.660 --> 13:25.300
We need to be paying attention to the packets per second to make sure that we

275
13:25.300 --> 13:26.020
're not putting

276
13:26.020 --> 13:30.260
a switch in place that has all the right port counts and port types even
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

276
13:26.020 --> 13:30.260
a switch in place that has all the right port counts and port types even

277
13:30.260 --> 13:31.180
supporting the

278
13:31.180 --> 13:32.820
right amount of bandwidth.

279
13:32.820 --> 13:37.770
But the overall performance from a packet's perspective, packets per second

280
13:37.770 --> 13:38.900
perspective is

281
13:38.900 --> 13:40.220
not enough.

282
13:40.220 --> 13:43.420
Now from a practical perspective, we might say, well, okay, but how many

283
13:43.420 --> 13:44.340
packets per second

284
13:44.340 --> 13:45.660
is enough?

285
13:45.660 --> 13:47.620
That's very difficult to evaluate.

286
13:47.620 --> 13:49.060
But here's the good news.

287
13:49.060 --> 13:53.580
When we go to Cisco's website, we're often going to be faced with a series of

288
13:53.580 --> 13:54.500
switches.

289
13:54.500 --> 14:00.420
So traditionally, Cisco used to have, let's say, 3650 and 3850 switches.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

289
13:54.500 --> 14:00.420
So traditionally, Cisco used to have, let's say, 3650 and 3850 switches.

290
14:00.420 --> 14:03.060
In the modern era, we have lots of catalysts, 9K.

291
14:03.060 --> 14:07.060
So 9300, 9400s, and so on and so forth.

292
14:07.060 --> 14:10.840
Well if we go out to Cisco's website, Cisco's going to tell us which of those

293
14:10.840 --> 14:12.220
switches is designed

294
14:12.220 --> 14:14.340
to be a network core.

295
14:14.340 --> 14:18.450
Now could I take a catalyst 9300 and turn it into a network core for a small

296
14:18.450 --> 14:19.420
organization?

297
14:19.420 --> 14:20.420
Absolutely.

298
14:20.420 --> 14:21.420
Sure I could.

299
14:21.420 --> 14:24.420
But Cisco will say, hey, but that's an access layer switch.

300
14:24.420 --> 14:27.140
So why can I get away with that?

301
14:27.140 --> 14:32.030
Well, because for a small network, if we have the right amount of port counts
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

301
14:27.140 --> 14:32.030
Well, because for a small network, if we have the right amount of port counts

302
14:32.030 --> 14:32.900
and port types

303
14:32.900 --> 14:37.090
in the packets per second, the performance of that switch is going to be enough

304
14:37.090 --> 14:37.260
for the

305
14:37.260 --> 14:38.500
smaller organization.

306
14:38.500 --> 14:44.250
But if I take it at 9300, plug it into the core for a global organization, they

307
14:44.250 --> 14:44.780
're not going

308
14:44.780 --> 14:49.150
to hold up very well because they can't keep up with the amount of packets that

309
14:49.150 --> 14:49.580
is trying

310
14:49.580 --> 14:51.220
to process at once.

311
14:51.220 --> 14:55.540
And furthermore, we might have issues with backplane over subscription.

312
14:55.540 --> 14:59.770
So instead, we can look at Cisco's website and say, okay, what do you recommend

313
14:59.770 --> 15:00.180
Cisco
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

313
14:59.770 --> 15:00.180
Cisco

314
15:00.180 --> 15:01.900
as a core network switch?

315
15:01.900 --> 15:07.080
Maybe that's a catalyst, 9500 or 9600 or whatever it ends up being by the time

316
15:07.080 --> 15:07.500
that you're

317
15:07.500 --> 15:11.030
going out to that website and taking a look at it because Cisco's portfolio is

318
15:11.030 --> 15:11.660
constantly

319
15:11.660 --> 15:12.860
evolving.

320
15:12.860 --> 15:16.580
When Cisco says it's a core switch, we can go out and look at the packets per

321
15:16.580 --> 15:17.140
second in

322
15:17.140 --> 15:18.820
the over subscription ratio.

323
15:18.820 --> 15:22.490
But we can expect that it's going to be good news because Cisco wouldn't be

324
15:22.490 --> 15:23.420
saying that

325
15:23.420 --> 15:27.370
they are creating a switch to be a core switch if it didn't have the proper

326
15:27.370 --> 15:29.140
performance metrics

327
15:29.140 --> 15:31.820
in order to serve in that role.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

327
15:29.140 --> 15:31.820
in order to serve in that role.