WEBVTT

1
00:00.000 --> 00:06.140
It's not going to be news to anybody taking this course that our network must

2
00:06.140 --> 00:07.120
be online

3
00:07.120 --> 00:09.520
as much as possible.

4
00:09.520 --> 00:14.600
Once upon a time, the network was nice to have, but these days it's absolutely

5
00:14.600 --> 00:15.560
required.

6
00:15.560 --> 00:19.970
The reason it's required is because our users can't do their jobs without

7
00:19.970 --> 00:20.920
having access

8
00:20.920 --> 00:24.720
to the applications that allow them to do their jobs.

9
00:24.720 --> 00:29.240
Yeah, maybe once upon a time again, we were able to do things with pencil and

10
00:29.240 --> 00:29.980
paper,

11
00:29.980 --> 00:34.930
but if I don't have access to my applications, then now I might as well just go
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

11
00:29.980 --> 00:34.930
but if I don't have access to my applications, then now I might as well just go

12
00:34.930 --> 00:35.620
home.

13
00:35.620 --> 00:39.750
I'm reminded of the time that I worked for a medical clinic and from my

14
00:39.750 --> 00:40.760
perspective,

15
00:40.760 --> 00:45.170
being in the IT department, I knew that I had to keep the wireless network

16
00:45.170 --> 00:46.180
online and one

17
00:46.180 --> 00:47.860
day it was starting to go down.

18
00:47.860 --> 00:51.630
We had this bizarre issue that we had to troubleshoot through and eventually we

19
00:51.630 --> 00:52.860
found the issue

20
00:52.860 --> 00:57.630
and we got it figured out, but it did take about an hour and a half, something

21
00:57.630 --> 00:58.660
like that.

22
00:58.660 --> 01:03.240
Well, it just so happened that my wife was going to the doctor that day at the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

22
00:58.660 --> 01:03.240
Well, it just so happened that my wife was going to the doctor that day at the

23
01:03.240 --> 01:03.860
very medical

24
01:03.860 --> 01:05.660
clinic at which I worked.

25
01:05.660 --> 01:11.080
She had our young son with her and they actually experienced the outage from

26
01:11.080 --> 01:12.820
the other side,

27
01:12.820 --> 01:17.600
where doctors and nurses were coming in and apologizing to her because our

28
01:17.600 --> 01:18.300
system is

29
01:18.300 --> 01:23.160
down and we can't do anything, we can't access medical records and we can't

30
01:23.160 --> 01:25.060
administer medications.

31
01:25.060 --> 01:29.860
Sure, there are some things that the doctor and nurse could do in the meantime,

32
01:29.860 --> 01:30.100
but for
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

32
01:29.860 --> 01:30.100
but for

33
01:30.100 --> 01:33.440
the most part they had to wait for the network to come online and they were

34
01:33.440 --> 01:34.260
really close to

35
01:34.260 --> 01:36.740
sending our home.

36
01:36.740 --> 01:40.960
It's a reminder to us that even though we sit on the networking side and we

37
01:40.960 --> 01:41.740
know we need

38
01:41.740 --> 01:45.540
to keep the network online, that real lives are affected.

39
01:45.540 --> 01:49.620
Not necessarily, like no lives were lost that day, not from that perspective,

40
01:49.620 --> 01:50.140
but from the

41
01:50.140 --> 01:57.060
perspective of the staff, the medical staff, they were embarrassed, they were

42
01:57.060 --> 01:58.260
flustered, they

43
01:58.260 --> 02:03.530
were frustrated, they were unable to do their jobs because the network went
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

43
01:58.260 --> 02:03.530
were frustrated, they were unable to do their jobs because the network went

44
02:03.530 --> 02:03.860
down.

45
02:03.860 --> 02:08.880
This is why we need to keep the network online as much as possible because, hey

46
02:08.880 --> 02:09.900
, I know that

47
02:09.900 --> 02:14.090
I want to be able to do my job and if technology gets in the way of that, my

48
02:14.090 --> 02:15.420
drawing tablet stops

49
02:15.420 --> 02:19.660
working, for example, it can be very frustrating because I just want to do my

50
02:19.660 --> 02:20.140
job.

51
02:20.140 --> 02:24.260
I don't want to have to deal with all these technical issues.

52
02:24.260 --> 02:28.540
So that's great, Null, except how do we go about doing it?

53
02:28.540 --> 02:30.860
Well there are two primary things to consider.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

53
02:28.540 --> 02:30.860
Well there are two primary things to consider.

54
02:30.860 --> 02:35.980
The first aspect of this is going to be fault tolerance.

55
02:35.980 --> 02:41.530
Fault tolerance asks the question, are there any single points of failure in

56
02:41.530 --> 02:42.460
the network

57
02:42.460 --> 02:48.900
or maybe more succinctly, can I survive a failure?

58
02:48.900 --> 02:52.990
We need to look at all aspects of the network in order to figure out if we can

59
02:52.990 --> 02:54.620
survive a failure.

60
02:54.620 --> 03:02.180
And again, the goal is to identify those single points of failures.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

60
02:54.620 --> 03:02.180
And again, the goal is to identify those single points of failures.

61
03:02.180 --> 03:07.260
If we can identify the single points of failures, then we can eliminate those

62
03:07.260 --> 03:07.940
and that's going

63
03:07.940 --> 03:11.620
to help us to survive when a failure does occur.

64
03:11.620 --> 03:15.210
It is important to throw out this entire conversation for us to recognize that

65
03:15.210 --> 03:16.620
failures do occur.

66
03:16.620 --> 03:18.700
We can't stop hardware from failing.

67
03:18.700 --> 03:24.380
We can't stop maybe protocols intersecting in ways that they shouldn't.

68
03:24.380 --> 03:29.140
I once actually took a pair of switches like this and we had a connection down

69
03:29.140 --> 03:30.020
to an access
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

69
03:29.140 --> 03:30.020
to an access

70
03:30.020 --> 03:36.190
layer switch and I plugged this access layer switch into the other distribution

71
03:36.190 --> 03:36.340
switch and

72
03:36.340 --> 03:46.340
it completed a loop.

73
03:46.340 --> 03:57.420
I plugged it and tried the exact same thing again and it worked just fine.

74
03:57.420 --> 03:58.420
That's technology.

75
03:58.420 --> 04:01.500
Sometimes it doesn't behave the way it's supposed to.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

75
03:58.420 --> 04:01.500
Sometimes it doesn't behave the way it's supposed to.

76
04:01.500 --> 04:05.720
So this is why we say we can't avoid failures. We just need to make sure that

77
04:05.720 --> 04:06.740
we have the ability

78
04:06.740 --> 04:10.060
to survive when a failure occurs.

79
04:10.060 --> 04:14.620
So we need to look at a few different aspects of this, especially as it relates

80
04:14.620 --> 04:16.060
to our network

81
04:16.060 --> 04:18.060
topologies.

82
04:18.060 --> 04:21.660
So what can we do to make sure we have no single points of failure?

83
04:21.660 --> 04:25.440
Well, we need to look at the critical parts of our network and make sure that

84
04:25.440 --> 04:25.820
we have

85
04:25.820 --> 04:28.820
redundant hardware.

86
04:28.820 --> 04:33.920
This is going to be a big part of this because, again, hardware can fail and if
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

86
04:28.820 --> 04:33.920
This is going to be a big part of this because, again, hardware can fail and if

87
04:33.920 --> 04:34.620
we lose a

88
04:34.620 --> 04:38.660
switch, we need another switch available to take over for it.

89
04:38.660 --> 04:43.160
So this is especially going to be true at the core block, the distribution, or

90
04:43.160 --> 04:43.780
data center

91
04:43.780 --> 04:46.340
aggregation block.

92
04:46.340 --> 04:51.180
And hey, even at the data center access layer, we might need redundancy and we

93
04:51.180 --> 04:51.580
'll talk

94
04:51.580 --> 04:53.780
about data center coming up.

95
04:53.780 --> 04:57.510
But we don't think about necessarily connecting a user lap top up to two

96
04:57.510 --> 04:58.500
different access

97
04:58.500 --> 05:02.290
layer switches, but in the data center, we'd absolutely want to connect our
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

97
04:58.500 --> 05:02.290
layer switches, but in the data center, we'd absolutely want to connect our

98
05:02.290 --> 05:02.900
servers up to

99
05:02.900 --> 05:06.820
multiple switches in case one piece of hardware goes down.

100
05:06.820 --> 05:11.500
We also want to look at appliances in our network.

101
05:11.500 --> 05:15.100
So when we're talking about appliances, we're usually talking about firewalls.

102
05:15.100 --> 05:19.620
We might be looking at load balancers, certainly wireless lane controllers.

103
05:19.620 --> 05:23.910
If we have multiple wireless lane controllers, then we need, at that point,

104
05:23.910 --> 05:24.780
hopefully we can

105
05:24.780 --> 05:27.020
survive a controller going down.

106
05:27.020 --> 05:30.580
But if we lose access to all of the wireless lane controllers in our
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

106
05:27.020 --> 05:30.580
But if we lose access to all of the wireless lane controllers in our

107
05:30.580 --> 05:32.180
environment, then our

108
05:32.180 --> 05:36.620
lightweight wireless architecture is going to come to a screeching halt.

109
05:36.620 --> 05:38.500
And that's not good for anybody.

110
05:38.500 --> 05:40.420
So those are some ways that we can look at this.

111
05:40.420 --> 05:48.290
We also want to look at the network connections because the network connections

112
05:48.290 --> 05:49.420
are going to

113
05:49.420 --> 05:52.940
define whether there are single points of failure as well because I can have

114
05:52.940 --> 05:53.460
hardware

115
05:53.460 --> 05:58.660
failure, but it doesn't do me any good if my hardware is connected like this.

116
05:58.660 --> 06:00.180
And so there's a redundant pair.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

116
05:58.660 --> 06:00.180
And so there's a redundant pair.

117
06:00.180 --> 06:02.980
And yet there's only a path in this way.

118
06:02.980 --> 06:07.820
So if this link goes down, I have no access to the redundant set.

119
06:07.820 --> 06:12.610
So we need to make sure, for example, that maybe we've got a pair of switches

120
06:12.610 --> 06:13.460
down here.

121
06:13.460 --> 06:17.300
And so we want to make sure we have a full mesh of connectivity.

122
06:17.300 --> 06:24.420
That's going to ensure that we maintain our online abilities and status if a

123
06:24.420 --> 06:25.100
particular

124
06:25.100 --> 06:29.740
piece of hardware or for that matter, a particular link were to go down.

125
06:29.740 --> 06:34.170
We also want to consider the concept of port channels or the Cisco term for
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

125
06:29.740 --> 06:34.170
We also want to consider the concept of port channels or the Cisco term for

126
06:34.170 --> 06:34.700
that is

127
06:34.700 --> 06:36.580
ether channels.

128
06:36.580 --> 06:42.180
If we have redundant connections between two devices, so now I've got a device

129
06:42.180 --> 06:42.820
here and

130
06:42.820 --> 06:45.820
a device over here and we need to connect them at layer two.

131
06:45.820 --> 06:50.060
Well, if I connect multiple connections like this, we're going to perform a

132
06:50.060 --> 06:50.900
banding tree

133
06:50.900 --> 06:53.460
blocking operation on one of those.

134
06:53.460 --> 06:58.140
And if the one of those links goes down, it's going to create spanning tree TCN

135
06:58.140 --> 06:58.700
s to flood

136
06:58.700 --> 06:59.820
the network.

137
06:59.820 --> 07:03.810
And so we're rather than allowing for us to run spanning tree here, we bundle
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

137
06:59.820 --> 07:03.810
And so we're rather than allowing for us to run spanning tree here, we bundle

138
07:03.810 --> 07:04.740
these connections

139
07:04.740 --> 07:08.700
together and ensure that it's a single logical link.

140
07:08.700 --> 07:13.050
That way if one of the connections goes down, it doesn't impact my layer to top

141
07:13.050 --> 07:13.700
ology.

142
07:13.700 --> 07:16.660
So that would be something to consider there as well.

143
07:16.660 --> 07:21.140
From here we can look at different protocols that we should be establishing.

144
07:21.140 --> 07:25.550
So if we're going to deploy redundancy at the protocol layer, what kinds of

145
07:25.550 --> 07:26.220
things should

146
07:26.220 --> 07:27.220
we be looking at?

147
07:27.220 --> 07:30.510
Well, from a layer three perspective, we absolutely want to be running a
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

147
07:27.220 --> 07:30.510
Well, from a layer three perspective, we absolutely want to be running a

148
07:30.510 --> 07:31.380
dynamic routing

149
07:31.380 --> 07:32.540
protocol.

150
07:32.540 --> 07:39.140
So OSPF or EIGRP or even BGP in larger environments.

151
07:39.140 --> 07:44.180
And that really is saying, hey, let's make sure that we're not running static

152
07:44.180 --> 07:44.940
routes.

153
07:44.940 --> 07:48.150
Even in a smaller environment, we might think that we could just deploy a few

154
07:48.150 --> 07:48.860
static routes

155
07:48.860 --> 07:50.100
here and there.

156
07:50.100 --> 07:54.550
But if a static route, maybe even one that's being injected into a dynamic

157
07:54.550 --> 07:55.660
protocol, if that

158
07:55.660 --> 07:59.740
goes away because a link goes down, well, that could actually cause a failure.

159
07:59.740 --> 08:03.800
So we want to rely on the dynamic nature of these routing protocols rather than
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

159
07:59.740 --> 08:03.800
So we want to rely on the dynamic nature of these routing protocols rather than

160
08:03.800 --> 08:04.300
static

161
08:04.300 --> 08:07.020
routes where it's possible to do so.

162
08:07.020 --> 08:10.670
And coming off our conversation, if you're working your way through the course

163
08:10.670 --> 08:11.540
sequentially,

164
08:11.540 --> 08:16.460
we just talked a lot about gateway redundancy via FHRP's.

165
08:16.460 --> 08:21.540
So that would be deploying HSRP, VRRP.

166
08:21.540 --> 08:26.180
And in some cases, maybe GLBP.

167
08:26.180 --> 08:31.100
Now from here, we want to look at other ways that we might experience a single
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

167
08:26.180 --> 08:31.100
Now from here, we want to look at other ways that we might experience a single

168
08:31.100 --> 08:31.500
point of

169
08:31.500 --> 08:33.940
failure without maybe even realizing it.

170
08:33.940 --> 08:37.270
As we just said for these connections, we want to make sure we have a full mesh

171
08:37.270 --> 08:37.660
and we've

172
08:37.660 --> 08:39.500
got port channels.

173
08:39.500 --> 08:41.140
But think about this.

174
08:41.140 --> 08:47.540
What happens if our pathing causes us problems?

175
08:47.540 --> 08:52.670
So I might look at a logical topology that I design and say, all right, I'm

176
08:52.670 --> 08:54.020
going to design

177
08:54.020 --> 08:56.740
redundancy into this solution.

178
08:56.740 --> 09:01.960
So I'm going to make sure that I have these two remote devices redundantly
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

178
08:56.740 --> 09:01.960
So I'm going to make sure that I have these two remote devices redundantly

179
09:01.960 --> 09:02.900
connecting

180
09:02.900 --> 09:06.020
to one another via a port channel.

181
09:06.020 --> 09:12.140
But because these devices are in two different buildings, I'm going to rely on

182
09:12.140 --> 09:12.540
fiber to connect

183
09:12.540 --> 09:13.540
the switches.

184
09:13.540 --> 09:16.740
So this looks like a redundant design from a logical perspective.

185
09:16.740 --> 09:20.060
However, what is happening physically?

186
09:20.060 --> 09:25.390
This is the question, especially when we're talking about some form of fiber

187
09:25.390 --> 09:26.460
connection,

188
09:26.460 --> 09:30.580
dark fiber, fiber that's in the ground that we're going to put optics to.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

188
09:26.460 --> 09:30.580
dark fiber, fiber that's in the ground that we're going to put optics to.

189
09:30.580 --> 09:35.480
So what happens if I have a physical building here and a physical building here

190
09:35.480 --> 09:35.580
?

191
09:35.580 --> 09:38.180
Let's say we're looking down at the building from the top.

192
09:38.180 --> 09:40.100
So these are the roofs of the building.

193
09:40.100 --> 09:43.780
And so I've got my Cisco device here and my Cisco device over here.

194
09:43.780 --> 09:46.500
And again, logically, they're directly connected to each other.

195
09:46.500 --> 09:51.610
But physically, one fiber connection comes out of the building here and comes

196
09:51.610 --> 09:52.260
around and

197
09:52.260 --> 09:53.780
goes, and okay, that's great.

198
09:53.780 --> 09:58.660
But what if the other fiber connection uses the exact same physical path?

199
09:58.660 --> 10:03.320
It wouldn't you know it, something comes by and cuts the conduit and breaks all
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

199
09:58.660 --> 10:03.320
It wouldn't you know it, something comes by and cuts the conduit and breaks all

200
10:03.320 --> 10:04.580
the fiber.

201
10:04.580 --> 10:06.100
What happened to my redundant design?

202
10:06.100 --> 10:10.420
It was just taken out with a single backhoe or crane or lawn mower.

203
10:10.420 --> 10:12.780
We've all heard probably plenty of those stories.

204
10:12.780 --> 10:16.300
They're all unfortunately very real and very true.

205
10:16.300 --> 10:20.250
So instead, we need to make sure that this other fiber connection takes a

206
10:20.250 --> 10:21.420
different physical

207
10:21.420 --> 10:22.580
path.

208
10:22.580 --> 10:27.590
So that if a backhoe comes by and digs up the fiber by mistake, and then at

209
10:27.590 --> 10:28.340
that point

210
10:28.340 --> 10:31.460
we still do have our redundant connection.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

210
10:28.340 --> 10:31.460
we still do have our redundant connection.

211
10:31.460 --> 10:36.270
So we do need to make sure that our path is secure when we have control over

212
10:36.270 --> 10:37.300
our own network.

213
10:37.300 --> 10:41.820
So this would be more of a local area network type of conversation.

214
10:41.820 --> 10:45.730
But then when we're looking at a wide area network conversation, especially

215
10:45.730 --> 10:47.020
with a, well,

216
10:47.020 --> 10:52.560
say an internet service provider, but it could just be a normal YN service

217
10:52.560 --> 10:52.620
provider.

218
10:52.620 --> 10:57.570
At that point, we need to ask the question of what about the service provider

219
10:57.570 --> 10:58.300
network?

220
10:58.300 --> 11:03.060
Because again, I could design a beautiful redundant solution and say that I'm
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

220
10:58.300 --> 11:03.060
Because again, I could design a beautiful redundant solution and say that I'm

221
11:03.060 --> 11:04.340
going to have my

222
11:04.340 --> 11:09.100
two edge devices communicating with two devices on the service provider.

223
11:09.100 --> 11:11.140
We're going to have a full mesh.

224
11:11.140 --> 11:15.100
And we've, you know, if any of my hardware goes down or your hardware goes down

225
11:15.100 --> 11:15.980
, we maintain

226
11:15.980 --> 11:16.980
uptime.

227
11:16.980 --> 11:17.980
And that's great.

228
11:17.980 --> 11:21.820
But what if both of the service provider routers connect to the same upstream

229
11:21.820 --> 11:22.460
device and

230
11:22.460 --> 11:23.780
it fails?

231
11:23.780 --> 11:26.660
Unfortunately, I've heard stories about this too.

232
11:26.660 --> 11:33.030
And so this kind of thing can actually cause that this beautiful redundant
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

232
11:26.660 --> 11:33.030
And so this kind of thing can actually cause that this beautiful redundant

233
11:33.030 --> 11:34.060
design to have

234
11:34.060 --> 11:35.660
a single point of failure.

235
11:35.660 --> 11:39.450
So usually because this is outside of our control, we need to at least be

236
11:39.450 --> 11:40.660
asking the questions

237
11:40.660 --> 11:45.830
and maybe even asking for some form of topology map that can prove that the

238
11:45.830 --> 11:46.940
service provider

239
11:46.940 --> 11:50.180
is giving me a redundant design.

240
11:50.180 --> 11:53.260
Now other than that, from a fault tolerance perspective, we can look at

241
11:53.260 --> 11:54.340
hardware components.

242
11:54.340 --> 11:59.470
For example, redundant supervisors, redundant power supplies, power supply

243
11:59.470 --> 12:00.420
units here.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

243
11:59.470 --> 12:00.420
units here.

244
12:00.420 --> 12:03.950
And if we have redundant power supply units, then we need to make sure that we

245
12:03.950 --> 12:04.740
have different

246
12:04.740 --> 12:05.740
circuits.

247
12:05.740 --> 12:08.630
So circuit A and circuit B, because if they're both plugged into the same

248
12:08.630 --> 12:09.420
circuit and that

249
12:09.420 --> 12:12.780
circuit pops, well, that we just boss both of our PSU.

250
12:12.780 --> 12:17.320
So same kind of thing here where we think we have redundancy, but we really don

251
12:17.320 --> 12:17.780
't.

252
12:17.780 --> 12:22.500
So lots of considerations that we should be making on the fault tolerance side.

253
12:22.500 --> 12:26.220
Now the second thing we need to consider, yes, that was all number one.

254
12:26.220 --> 12:28.620
Now we're on to number two.

255
12:28.620 --> 12:32.820
Number two here would be high availability.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

255
12:28.620 --> 12:32.820
Number two here would be high availability.

256
12:32.820 --> 12:37.900
And high availability conversation is actually one that is meant to find a

257
12:37.900 --> 12:39.100
balance between

258
12:39.100 --> 12:44.980
the amount of fault tolerance that we're going to deploy and the amount of

259
12:44.980 --> 12:46.060
money that we're

260
12:46.060 --> 12:47.540
going to spend.

261
12:47.540 --> 12:53.240
And this ultimately, in most cases, is going to be a management decision, but

262
12:53.240 --> 12:53.620
they can't

263
12:53.620 --> 12:56.740
make that decision if we don't provide the amount of data.

264
12:56.740 --> 13:02.210
So what we're saying here is essentially, how up are we going to be, or maybe
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

264
12:56.740 --> 13:02.210
So what we're saying here is essentially, how up are we going to be, or maybe

265
13:02.210 --> 13:02.980
we should

266
13:02.980 --> 13:11.020
say, how much downtime are we going to allow down downtown, down time?

267
13:11.020 --> 13:12.020
There we go.

268
13:12.020 --> 13:14.500
How much downtime will we allow?

269
13:14.500 --> 13:16.860
And again, this should be a management decision.

270
13:16.860 --> 13:21.410
Now every manager, at least if, unless they have an ID background, they're

271
13:21.410 --> 13:22.460
going to come back

272
13:22.460 --> 13:27.780
and say we want to be 100% uptime or 100% up.

273
13:27.780 --> 13:28.780
And okay, that's great.

274
13:28.780 --> 13:33.890
I just need $14 million in order to ensure 100% uptime because the reality is
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

274
13:28.780 --> 13:33.890
I just need $14 million in order to ensure 100% uptime because the reality is

275
13:33.890 --> 13:34.820
that we can't

276
13:34.820 --> 13:37.180
ever guarantee 100% uptime.

277
13:37.180 --> 13:41.460
We said it over here that failures are going to happen.

278
13:41.460 --> 13:47.340
And even in the most robust, securely designed networks, failures will occur.

279
13:47.340 --> 13:52.290
And we hear about those failures pretty commonly from major vendors who you'd

280
13:52.290 --> 13:53.100
think would

281
13:53.100 --> 13:57.940
have a very robust network design and they probably did.

282
13:57.940 --> 14:00.020
So it's not about 100%.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

282
13:57.940 --> 14:00.020
So it's not about 100%.

283
14:00.020 --> 14:03.660
It's usually about the nine's conversation.

284
14:03.660 --> 14:06.340
How many nines of uptime do we want?

285
14:06.340 --> 14:11.190
So for example, if I say I want a 99% uptime, this would be two nines of uptime

286
14:11.190 --> 14:12.180
because there's

287
14:12.180 --> 14:14.660
two nines in the number of 99.

288
14:14.660 --> 14:20.300
Or if I can say, let's go to 99.9% uptime, well now that's three nines of up

289
14:20.300 --> 14:21.300
time and so on

290
14:21.300 --> 14:22.540
and so forth.

291
14:22.540 --> 14:27.900
So maybe we'll say 99.99% uptime.

292
14:27.900 --> 14:34.340
And we might even be able to get a conversation going where we have five nines.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

292
14:27.900 --> 14:34.340
And we might even be able to get a conversation going where we have five nines.

293
14:34.340 --> 14:38.580
Six nines is, yeah, you're really getting up there at that point.

294
14:38.580 --> 14:42.470
Now anytime we're talking about a percentage, we can apply it back to the

295
14:42.470 --> 14:43.580
strictly speaking

296
14:43.580 --> 14:46.820
the number of hours and minutes we have in the year.

297
14:46.820 --> 15:03.580
So we have a random calculation here, 8,760 hours and 525,600 minutes per year.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

297
14:46.820 --> 15:03.580
So we have a random calculation here, 8,760 hours and 525,600 minutes per year.

298
15:03.580 --> 15:08.440
So if I'm going to say 99% uptime, well I can look at my hours there and take

299
15:08.440 --> 15:09.220
one percent

300
15:09.220 --> 15:18.900
of that basically and say that we can be down for 87.6 hours a year.

301
15:18.900 --> 15:21.660
Holy moly, that's more than three days.

302
15:21.660 --> 15:25.540
99% sounds great, but it's really low bar.

303
15:25.540 --> 15:27.780
We probably want to do a little better than that.

304
15:27.780 --> 15:33.100
Now if we advance to 99.9, we can divide that number by 10, essentially.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

304
15:27.780 --> 15:33.100
Now if we advance to 99.9, we can divide that number by 10, essentially.

305
15:33.100 --> 15:37.380
And so we're talking about still 8.76 hours.

306
15:37.380 --> 15:41.840
And if we get to 49, at that point we're below an hour, 0.876 hours that

307
15:41.840 --> 15:44.700
translates to 52.

308
15:44.700 --> 15:51.140
We look at this number over here, we can round that up to 0.6 minutes.

309
15:51.140 --> 15:53.260
And a lot of networks aim for 49.

310
15:53.260 --> 15:57.820
It's a pretty good balance of cost versus acceptable outages.

311
15:57.820 --> 16:03.740
And if we want to go to 59, then we're at 5.26 minutes.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

311
15:57.820 --> 16:03.740
And if we want to go to 59, then we're at 5.26 minutes.

312
16:03.740 --> 16:09.440
And if we go to 6.9s at that point, we are about a half a minute, roughly 31.5

313
16:09.440 --> 16:10.060
seconds

314
16:10.060 --> 16:12.340
of outages per year.

315
16:12.340 --> 16:17.130
Now the problem with this is that as we go up the scale or down the scale, how

316
16:17.130 --> 16:17.740
we want

317
16:17.740 --> 16:20.140
to say this, it's going to require more money.

318
16:20.140 --> 16:25.450
We need higher resiliency switches with redundant power supplies, redundant

319
16:25.450 --> 16:26.180
circuits, now

320
16:26.180 --> 16:31.030
become redundant power grids, redundant service provider connections become
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

320
16:26.180 --> 16:31.030
become redundant power grids, redundant service provider connections become

321
16:31.030 --> 16:32.060
redundant path

322
16:32.060 --> 16:33.060
connections.

323
16:33.060 --> 16:38.660
We need to maybe dig more fiber and deploy more complex protocols.

324
16:38.660 --> 16:42.700
It might require additional staff and better monitoring tools.

325
16:42.700 --> 16:47.100
We have a lot of needs if we're going to talk about that level of high

326
16:47.100 --> 16:48.340
availability.

327
16:48.340 --> 16:51.860
And unfortunately limitless budgets don't exist.

328
16:51.860 --> 16:56.640
So fortunately at the end of the day, as IT engineers, this is still a

329
16:56.640 --> 16:58.620
management decision.

330
16:58.620 --> 17:02.350
But we have to provide them with all of the information required in order to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

330
16:58.620 --> 17:02.350
But we have to provide them with all of the information required in order to

331
17:02.350 --> 17:02.900
make that

332
17:02.900 --> 17:03.900
decision.

333
17:03.900 --> 17:06.020
And then if they decide, hey, you know what?

334
17:06.020 --> 17:11.890
Yeah, we want 100% uptime, but we're only going to give you budget for 3.9s of

335
17:11.890 --> 17:12.700
uptime.

336
17:12.700 --> 17:15.580
Well, okay, at least we've spoken our piece.

337
17:15.580 --> 17:20.280
We've communicated that we can still expect up to 8 hours, maybe even up to 9

338
17:20.280 --> 17:20.820
hours of

339
17:20.820 --> 17:23.660
downtime a year at this budget level.

340
17:23.660 --> 17:27.540
And they're just going to have to deal with that when the time comes.

341
17:27.540 --> 17:30.140
But at least at that point, we have done our due diligence.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

341
17:27.540 --> 17:30.140
But at least at that point, we have done our due diligence.

342
17:30.140 --> 17:33.060
We have provided all the redundancy that we can.

343
17:33.060 --> 17:36.140
We have considered all of the single points of failure in the network.

344
17:36.140 --> 17:40.270
And we have designed as robust of a network as we can given the existing budget

345
17:40.270 --> 17:41.300
ary constraints.