WEBVTT

1
00:00.000 --> 00:05.010
Well, another form of network redundancy we should consider has to do with

2
00:05.010 --> 00:06.440
hardware redundancy,

3
00:06.440 --> 00:10.540
but we're not just talking about having two sets of hardware, we're talking

4
00:10.540 --> 00:11.960
about within

5
00:11.960 --> 00:13.920
a set of hardware.

6
00:13.920 --> 00:18.780
Because if I have a fixed configuration switch, meaning it's just a single rack

7
00:18.780 --> 00:19.360
unit, a bunch

8
00:19.360 --> 00:23.490
of ports on it, and it has a hardware failure, well, the whole thing has gone

9
00:23.490 --> 00:24.040
down.

10
00:24.040 --> 00:28.520
And ideally, I have a second device here, and I can redirect my traffic from

11
00:28.520 --> 00:29.200
one device

12
00:29.200 --> 00:30.200
to the other.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

12
00:29.200 --> 00:30.200
to the other.

13
00:30.200 --> 00:35.440
But what about a network device like a chassis switch?

14
00:35.440 --> 00:41.350
A chassis switch is built to be modular, and there are two different types of

15
00:41.350 --> 00:42.240
modules.

16
00:42.240 --> 00:48.060
We have the supervisor, which is the intelligence part of the chassis, and then

17
00:48.060 --> 00:49.200
we have individual

18
00:49.200 --> 00:50.760
line cards.

19
00:50.760 --> 00:54.730
So the supervisor is really in charge of the control plane, and the line cards

20
00:54.730 --> 00:55.160
are what

21
00:55.160 --> 00:57.320
handle the data plane.

22
00:57.320 --> 01:01.080
Now let's make sure that we have a good grasp of control plane versus data
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

22
00:57.320 --> 01:01.080
Now let's make sure that we have a good grasp of control plane versus data

23
01:01.080 --> 01:02.080
plane, because

24
01:02.080 --> 01:08.210
the idea of a chassis being redundant is that we would have two supervisors,

25
01:08.210 --> 01:08.680
and if one

26
01:08.680 --> 01:13.140
of these supervisors goes down, the active supervisor, then we would want this

27
01:13.140 --> 01:13.980
device to stay

28
01:13.980 --> 01:15.960
online and operational.

29
01:15.960 --> 01:19.620
But we can't just say that, well, we have two supervisors, and so we're good to

30
01:19.620 --> 01:20.000
go.

31
01:20.000 --> 01:23.950
We're going to need some techniques on the back end in order to make sure that

32
01:23.950 --> 01:24.680
everything

33
01:24.680 --> 01:26.200
stays forwarding.

34
01:26.200 --> 01:29.760
And it does have to do with the control plane and the data plane.

35
01:29.760 --> 01:35.930
So when we think about it, if a packet comes in to a device, we're going to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

35
01:29.760 --> 01:35.930
So when we think about it, if a packet comes in to a device, we're going to

36
01:35.930 --> 01:36.940
check some

37
01:36.940 --> 01:40.200
kind of table.

38
01:40.200 --> 01:44.040
And this table is going to determine how we forward it.

39
01:44.040 --> 01:46.520
So this might be a routing table at layer three.

40
01:46.520 --> 01:51.450
It could be a cam table at layer two, but it's going to allow us to pick a port

41
01:51.450 --> 01:51.560
and

42
01:51.560 --> 01:52.880
forward it out.

43
01:52.880 --> 01:57.880
And this would be known as the data plane of operations.

44
01:57.880 --> 02:02.400
Well that's well and good, except where does this table get its information?
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

44
01:57.880 --> 02:02.400
Well that's well and good, except where does this table get its information?

45
02:02.400 --> 02:04.840
Well that would be the control plane.

46
02:04.840 --> 02:10.640
So I'm going to run a protocol like EIGRP or OSPF or at layer two.

47
02:10.640 --> 02:16.700
I'm just going to learn the control plane by forwarding traffic, and I populate

48
02:16.700 --> 02:16.800
this

49
02:16.800 --> 02:18.960
table.

50
02:18.960 --> 02:24.140
And the way I do that at the control plane is by forming adjacencies with other

51
02:24.140 --> 02:25.040
devices.

52
02:25.040 --> 02:26.760
So I've got another device over here.

53
02:26.760 --> 02:29.000
I've got another device over here.

54
02:29.000 --> 02:33.980
And I am forming a partnership with them with the EIGRP and adjacency at OSPF,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

54
02:29.000 --> 02:33.980
And I am forming a partnership with them with the EIGRP and adjacency at OSPF,

55
02:33.980 --> 02:35.240
the terminology

56
02:35.240 --> 02:36.320
changes.

57
02:36.320 --> 02:42.530
But in the end, we're exchanging information with one another so I can form the

58
02:42.530 --> 02:43.240
information

59
02:43.240 --> 02:46.600
that goes into those tables that enable the data plane.

60
02:46.600 --> 02:51.890
So once again, thinking about the fact that my supervisor has just gone down

61
02:51.890 --> 02:52.960
and the supervisor's

62
02:52.960 --> 02:56.790
in charge of control plane operations, meaning I'm bringing packets in and

63
02:56.790 --> 02:57.360
evaluating

64
02:57.360 --> 03:01.360
them and changing the table if needed and all of those things.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

64
02:57.360 --> 03:01.360
them and changing the table if needed and all of those things.

65
03:01.360 --> 03:07.600
Well if I lose the control plane, then I have just lost the information that I

66
03:07.600 --> 03:08.520
was populating

67
03:08.520 --> 03:10.040
in the table.

68
03:10.040 --> 03:14.240
And so as a result, the data plane goes down.

69
03:14.240 --> 03:17.480
This is the danger that we have in this scenario.

70
03:17.480 --> 03:21.740
And so we have to think through, okay, what is the failover process going to be

71
03:21.740 --> 03:22.240
looking

72
03:22.240 --> 03:23.240
like?

73
03:23.240 --> 03:26.810
Well when we look at things from a classical perspective, back when chassis

74
03:26.810 --> 03:27.360
switches

75
03:27.360 --> 03:31.520
first came out, we had a cold standby procedure.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

75
03:27.360 --> 03:31.520
first came out, we had a cold standby procedure.

76
03:31.520 --> 03:35.600
Cold standby said that we have a redundant supervisor.

77
03:35.600 --> 03:36.600
So that's good.

78
03:36.600 --> 03:44.000
In fact, we'll just call this the failover supervisor.

79
03:44.000 --> 03:51.160
So we have a failover soup and it is waiting for the primary to fail.

80
03:51.160 --> 03:56.240
As soon as the primary fails, we're going to boot up that supervisor, which is

81
03:56.240 --> 03:56.800
going to

82
03:56.800 --> 04:02.280
take some time, then we are going to form those adjacencies or those neighbors
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

82
03:56.800 --> 04:02.280
take some time, then we are going to form those adjacencies or those neighbors

83
04:02.280 --> 04:03.240
hips with other

84
04:03.240 --> 04:08.120
devices and then we're going to populate the table.

85
04:08.120 --> 04:12.670
But notice the entire time that the control plane is sitting here working, the

86
04:12.670 --> 04:13.760
data plane

87
04:13.760 --> 04:15.520
is actually down.

88
04:15.520 --> 04:18.240
We don't have any information in those tables.

89
04:18.240 --> 04:24.480
So this could actually be several minutes of downtime.

90
04:24.480 --> 04:29.210
Now is that better than being down for hours waiting for new hardware to show

91
04:29.210 --> 04:29.680
up?

92
04:29.680 --> 04:30.680
Sure.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

92
04:29.680 --> 04:30.680
Sure.

93
04:30.680 --> 04:34.320
But that's still minutes of an outage that we might think that we could do

94
04:34.320 --> 04:35.120
better with,

95
04:35.120 --> 04:40.480
especially since our failover supervisor is sitting there inside the chassis.

96
04:40.480 --> 04:45.680
So instead, we're going to develop a couple of procedures and processes that's

97
04:45.680 --> 04:46.080
going

98
04:46.080 --> 04:48.800
to enable us to do this faster.

99
04:48.800 --> 04:53.110
And it's going to involve two separate processes, the first of which is known

100
04:53.110 --> 04:57.680
as stateful switchover,

101
04:57.680 --> 05:04.200
which is abbreviated as SSO.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

101
04:57.680 --> 05:04.200
which is abbreviated as SSO.

102
05:04.200 --> 05:09.920
The idea of stateful switchover is to maintain the state of operation while the

103
05:09.920 --> 05:10.840
switchover

104
05:10.840 --> 05:12.360
is happening.

105
05:12.360 --> 05:16.750
This is going to involve a couple of facets to this, but really what it

106
05:16.750 --> 05:17.720
involves is the

107
05:17.720 --> 05:20.920
fact that I need to maintain the control plane.

108
05:20.920 --> 05:22.120
Here's the problem.

109
05:22.120 --> 05:29.770
If I have two supervisors and the active is here on the left and the redundant

110
05:29.770 --> 05:30.520
ones there
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

110
05:29.770 --> 05:30.520
ones there

111
05:30.520 --> 05:36.120
on the right, I have all of my tables populated here on the supervisor.

112
05:36.120 --> 05:38.600
And the tables over here are completely empty.

113
05:38.600 --> 05:41.840
So if supervisor A goes down, I can't forward traffic.

114
05:41.840 --> 05:45.440
Again, the data plane has gone down because I lost all the information that was

115
05:45.440 --> 05:45.840
sitting

116
05:45.840 --> 05:47.400
there in the table.

117
05:47.400 --> 05:52.820
So what stateful switchover says is, first of all, we're going to have the

118
05:52.820 --> 05:53.360
redundant

119
05:53.360 --> 06:01.840
soup online and fully synchronized.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

119
05:53.360 --> 06:01.840
soup online and fully synchronized.

120
06:01.840 --> 06:05.440
We're going to sync the control plane information.

121
06:05.440 --> 06:10.340
What this means is that if I populate information into the table for the active

122
06:10.340 --> 06:11.200
soup, I'm going

123
06:11.200 --> 06:15.280
to populate the table here in the backup soup as well.

124
06:15.280 --> 06:19.750
This improves my ability to fail over in one important way, which is, first of

125
06:19.750 --> 06:20.400
all, the

126
06:20.400 --> 06:22.560
redundant soup is already online.

127
06:22.560 --> 06:25.900
Meaning that I don't have to power this thing up from a cold standby

128
06:25.900 --> 06:26.840
perspective.

129
06:26.840 --> 06:30.140
But the other thing to consider is the fact that I'm actually synchronizing the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

129
06:26.840 --> 06:30.140
But the other thing to consider is the fact that I'm actually synchronizing the

130
06:30.140 --> 06:30.520
control

131
06:30.520 --> 06:31.520
plane.

132
06:31.520 --> 06:34.080
And that creates an interesting situation.

133
06:34.080 --> 06:37.430
Because when we look back at our diagram at the top here, if the control plane

134
06:37.430 --> 06:38.120
now goes

135
06:38.120 --> 06:43.590
down, meaning the supervisor failed, we still have a table that is fully

136
06:43.590 --> 06:45.080
populated here

137
06:45.080 --> 06:49.720
on supervisor B, meaning that the data plane can stay online.

138
06:49.720 --> 06:53.990
Now there might be still a few seconds for us to detect that the primary is

139
06:53.990 --> 06:54.600
down.

140
06:54.600 --> 07:00.050
And then therefore we're going to have to maybe still drop some packets for a
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

140
06:54.600 --> 07:00.050
And then therefore we're going to have to maybe still drop some packets for a

141
07:00.050 --> 07:01.200
few seconds.

142
07:01.200 --> 07:05.810
But as soon as we direct our traffic through this backup supervisor, this table

143
07:05.810 --> 07:06.320
is fully

144
07:06.320 --> 07:09.480
populated and the data plane is online.

145
07:09.480 --> 07:14.240
Now that's well and good, other than the fact that we do still have another

146
07:14.240 --> 07:15.040
problem, which

147
07:15.040 --> 07:20.030
is that we had these adjacencies and we were maintaining the information from

148
07:20.030 --> 07:21.200
our adjacencies

149
07:21.200 --> 07:25.800
as part of maintaining the control plane operation.

150
07:25.800 --> 07:32.120
So we need a mechanism to maintain those relationships.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

150
07:25.800 --> 07:32.120
So we need a mechanism to maintain those relationships.

151
07:32.120 --> 07:36.120
And so that is going to lead us to non-stop forwarding.

152
07:36.120 --> 07:40.000
Actually, we'll write it out here.

153
07:40.000 --> 07:44.200
Non-stop forwarding or NSF.

154
07:44.200 --> 07:54.880
Not forwarding is going to help us to basically maintain the adjacencies or the

155
07:54.880 --> 07:55.760
neighborships,

156
07:55.760 --> 08:03.600
depending on whether we're running OSPF or EIGRP, Jsoncees.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

156
07:55.760 --> 08:03.600
depending on whether we're running OSPF or EIGRP, Jsoncees.

157
08:03.600 --> 08:06.440
So we're going to be able to maintain those adjacencies.

158
08:06.440 --> 08:11.760
In order to do this, we're going to have to let the other devices know that we

159
08:11.760 --> 08:12.680
have NSF

160
08:12.680 --> 08:13.680
enabled.

161
08:13.680 --> 08:18.080
And first of all, we enable NSF ourselves.

162
08:18.080 --> 08:21.800
And then we let the others know that we are NSF capable.

163
08:21.800 --> 08:27.040
We say, hey, by the way, we would like to use NSF here in case we go down.

164
08:27.040 --> 08:32.720
And by the way, we need both of these devices to also be NSF capable.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

164
08:27.040 --> 08:32.720
And by the way, we need both of these devices to also be NSF capable.

165
08:32.720 --> 08:38.120
So this is something that is going to be requiring support at multiple levels.

166
08:38.120 --> 08:41.760
Not only on the chassis, but also on the remote devices.

167
08:41.760 --> 08:47.970
But the idea here is that when we go down, we have an amount of grace time to

168
08:47.970 --> 08:48.840
get back

169
08:48.840 --> 08:50.360
online.

170
08:50.360 --> 08:53.160
Because we might be running millisecond timers and we might say, hey, you've

171
08:53.160 --> 08:53.800
been down for

172
08:53.800 --> 08:55.000
a second and a half.

173
08:55.000 --> 09:00.050
I'm going to completely drop this connection, which means I'm updating the own
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

173
08:55.000 --> 09:00.050
I'm going to completely drop this connection, which means I'm updating the own

174
09:00.050 --> 09:00.400
info or the

175
09:00.400 --> 09:02.720
info in my own routing table.

176
09:02.720 --> 09:04.520
We don't want a whole convergence event.

177
09:04.520 --> 09:07.640
We don't want everybody to be shifting routes around.

178
09:07.640 --> 09:15.910
Instead, the idea here is that we're essentially, we're going to freeze the

179
09:15.910 --> 09:17.640
control plane, at

180
09:17.640 --> 09:21.800
least as far as the information that involves this one chassis.

181
09:21.800 --> 09:23.560
Now how long are we freezing this?

182
09:23.560 --> 09:27.760
Well, overall, this should happen in a matter of seconds, as we mentioned.

183
09:27.760 --> 09:29.680
We have to detect that there's an outage.

184
09:29.680 --> 09:33.440
We have to flip over to the redundant supervisor.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

184
09:29.680 --> 09:33.440
We have to flip over to the redundant supervisor.

185
09:33.440 --> 09:37.190
Then we need to activate that and get it online and start sending control plane

186
09:37.190 --> 09:38.160
information.

187
09:38.160 --> 09:42.440
For several seconds, we're going to be in a place where we have to trust that

188
09:42.440 --> 09:44.040
this information

189
09:44.040 --> 09:45.440
hasn't changed.

190
09:45.440 --> 09:50.580
If there are changes, there's routes that have changed or routes that are no

191
09:50.580 --> 09:51.720
longer valid,

192
09:51.720 --> 09:55.530
well, I'm going to still be forwarding traffic out my interfaces as if that

193
09:55.530 --> 09:56.440
information is

194
09:56.440 --> 10:01.680
valid because this table was frozen in time during the NSF process.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

194
09:56.440 --> 10:01.680
valid because this table was frozen in time during the NSF process.

195
10:01.680 --> 10:05.960
What it does is it prevents these adjacencies from going down and it allows the

196
10:05.960 --> 10:06.880
other devices

197
10:06.880 --> 10:10.440
to know, okay, we're in the middle of an NSF event here, clearly.

198
10:10.440 --> 10:13.840
We're going to show some grace while that device figures it out.

199
10:13.840 --> 10:17.520
Once it's online, we don't have to reestablish the adjacencies.

200
10:17.520 --> 10:22.400
We maintain those adjacencies and it keeps the layer three network stable.

201
10:22.400 --> 10:28.000
In the meantime, the NSF capable device out here, it's going to mark its routes

202
10:28.000 --> 10:29.720
as stale,

203
10:29.720 --> 10:33.210
meaning that they haven't been updated in a while, they might not be up to date
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

203
10:29.720 --> 10:33.210
meaning that they haven't been updated in a while, they might not be up to date

204
10:33.210 --> 10:33.320
.

205
10:33.320 --> 10:37.450
Then, so this is the first step here, and the second step is then I'm going to

206
10:37.450 --> 10:39.040
send a graceful

207
10:39.040 --> 10:44.760
restart message to say I'm back online and functional.

208
10:44.760 --> 10:48.280
At that point, if any information had changed while that device was down, we'll

209
10:48.280 --> 10:48.800
get that

210
10:48.800 --> 10:54.690
update being sent from the NSF capable devices and we will be back online and

211
10:54.690 --> 10:55.840
functional,

212
10:55.840 --> 10:59.510
so hopefully the network was just stable and we took a few seconds to switch

213
10:59.510 --> 11:00.000
over to the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

214
11:00.000 --> 11:02.560
new supervisor and everything stays online.

215
11:02.560 --> 11:04.520
We never dropped any adjacencies.

216
11:04.520 --> 11:07.780
Our neighbors never had to pull any routes and it keeps our layer three network

217
11:07.780 --> 11:08.280
online and

218
11:08.280 --> 11:11.280
stable even through this hardware failure.

219
11:11.280 --> 11:21.280
[BLANK_AUDIO]