1
00:00:00,000 --> 00:00:03,318
[AUDIO LOGO]

2
00:00:03,318 --> 00:00:07,110

3
00:00:07,110 --> 00:00:12,210
So let's begin by talking about
two technologies that help us

4
00:00:12,210 --> 00:00:16,770
with convergence performance in
the event of a route processor

5
00:00:16,770 --> 00:00:17,880
failure.

6
00:00:17,880 --> 00:00:19,650
The first one we're
going to look at

7
00:00:19,650 --> 00:00:23,160
is NSF, or non-stop forwarding.

8
00:00:23,160 --> 00:00:28,180
And the other one is
NSR, non-stop routing.

9
00:00:28,180 --> 00:00:32,130
Now, these do perform
the same basic role.

10
00:00:32,130 --> 00:00:38,010
So generally speaking, if we
have NSR, we don't need NSF.

11
00:00:38,010 --> 00:00:41,010
So we'll talk about that as
we go through the details

12
00:00:41,010 --> 00:00:42,240
of each one.

13
00:00:42,240 --> 00:00:45,900
Something else to note here,
we can see this a little bit

14
00:00:45,900 --> 00:00:48,310
on the command line in our lab.

15
00:00:48,310 --> 00:00:50,440
So we'll jump in
and look at that.

16
00:00:50,440 --> 00:00:53,760
But be aware that our lab
is all virtual routers,

17
00:00:53,760 --> 00:00:56,790
and they do not have
redundant route processors.

18
00:00:56,790 --> 00:01:00,300
Therefore, we can't actually
see this in operation.

19
00:01:00,300 --> 00:01:03,780
But the most important thing
is to understand what it does

20
00:01:03,780 --> 00:01:06,790
and how both of these
technologies work.

21
00:01:06,790 --> 00:01:09,300
So let's go ahead and jump in
and talk about the details.

22
00:01:09,300 --> 00:01:10,830
And then we'll see
what little bit

23
00:01:10,830 --> 00:01:14,750
we can see at the command line.

24
00:01:14,750 --> 00:01:18,460
So as we said during
the introduction, NSF,

25
00:01:18,460 --> 00:01:23,710
or non-stop forwarding, and
non-stop routing, or NSR,

26
00:01:23,710 --> 00:01:27,670
are both technologies
that help us with--

27
00:01:27,670 --> 00:01:31,450
well, we say stability
here or with convergence

28
00:01:31,450 --> 00:01:35,320
during RP switchovers,
hopefully,

29
00:01:35,320 --> 00:01:39,610
avoiding any convergence
time at all, particularly

30
00:01:39,610 --> 00:01:43,430
with NSR, non-stop routing.

31
00:01:43,430 --> 00:01:45,850
So let's jump in and
talk about more details

32
00:01:45,850 --> 00:01:47,720
on each one of these.

33
00:01:47,720 --> 00:01:50,260
Let's start with NSF.

34
00:01:50,260 --> 00:01:54,820
So the idea here is
it allows forwarding

35
00:01:54,820 --> 00:02:00,070
to continue, hence the
name non-stop forwarding,

36
00:02:00,070 --> 00:02:03,490
using known routes.

37
00:02:03,490 --> 00:02:06,490
Of course, if the
route processor fails,

38
00:02:06,490 --> 00:02:09,400
that means that our
neighborships and such will go

39
00:02:09,400 --> 00:02:11,540
down in our routing protocols.

40
00:02:11,540 --> 00:02:15,800
So the idea with these
known routes, well, twofold.

41
00:02:15,800 --> 00:02:19,360
First, our neighbors have to
use the routes they already

42
00:02:19,360 --> 00:02:21,490
knew to forward traffic to us.

43
00:02:21,490 --> 00:02:25,000
And we have to use the
routes that we already

44
00:02:25,000 --> 00:02:28,300
knew that are learned
on our line cards.

45
00:02:28,300 --> 00:02:31,000
So this will be doing
forwarding based

46
00:02:31,000 --> 00:02:36,470
on already known information
until the failover is complete.

47
00:02:36,470 --> 00:02:38,930
Now, as we jump
into detail here,

48
00:02:38,930 --> 00:02:41,500
be aware that there are
two versions of this.

49
00:02:41,500 --> 00:02:44,770
There is a Cisco
proprietary version

50
00:02:44,770 --> 00:02:47,590
and an IETF standard version.

51
00:02:47,590 --> 00:02:50,620
Cisco routers can
support either one.

52
00:02:50,620 --> 00:02:53,390
We'll talk about
that here as we go.

53
00:02:53,390 --> 00:02:57,650
Now, the routers themselves
fall into three categories.

54
00:02:57,650 --> 00:03:02,920
The first is what
we call NSF-capable.

55
00:03:02,920 --> 00:03:06,070
This is the router that
we would say is actually

56
00:03:06,070 --> 00:03:09,220
doing the non-stop forwarding.

57
00:03:09,220 --> 00:03:12,700
This is the router that has
the dual-route processors.

58
00:03:12,700 --> 00:03:15,070
Keep in mind none
of this can happen

59
00:03:15,070 --> 00:03:19,160
unless the router has dual-route
processors because, of course,

60
00:03:19,160 --> 00:03:21,010
we're failing over
to the other one.

61
00:03:21,010 --> 00:03:22,720
That's the point.

62
00:03:22,720 --> 00:03:26,980
Part of what it's going to have
to do after the failover is

63
00:03:26,980 --> 00:03:31,600
it's going to have to
relearn the IS-IS neighbors.

64
00:03:31,600 --> 00:03:36,760
And the key here is we have
to do this without causing

65
00:03:36,760 --> 00:03:38,830
actual neighbor resets.

66
00:03:38,830 --> 00:03:41,230
If we reset our
neighborships, we

67
00:03:41,230 --> 00:03:44,530
will wipe out the
IS-IS database and have

68
00:03:44,530 --> 00:03:46,450
to learn everything over again.

69
00:03:46,450 --> 00:03:48,700
Being able to rebuild
the neighborships

70
00:03:48,700 --> 00:03:52,600
without a full reset
does require that we

71
00:03:52,600 --> 00:03:54,940
have the link-state database.

72
00:03:54,940 --> 00:03:57,290
Now, once the
neighborships come up,

73
00:03:57,290 --> 00:04:00,940
we will refresh that link-state
database and recalculate

74
00:04:00,940 --> 00:04:02,860
anything we need to.

75
00:04:02,860 --> 00:04:07,100
And there's one more super
key factor for this to work.

76
00:04:07,100 --> 00:04:10,690
We have to signal our
neighboring routers

77
00:04:10,690 --> 00:04:14,180
that a failover is occurring.

78
00:04:14,180 --> 00:04:17,570
Our neighbors here are
going to have to be aware

79
00:04:17,570 --> 00:04:19,820
that we're doing a failover.

80
00:04:19,820 --> 00:04:22,970
The reason this is so
critical is otherwise,

81
00:04:22,970 --> 00:04:24,800
when our route
processor goes down

82
00:04:24,800 --> 00:04:27,380
and our neighborships
go down, just

83
00:04:27,380 --> 00:04:31,040
like we would remove all the
routes from our routing table

84
00:04:31,040 --> 00:04:33,090
if it weren't for
non-stop forwarding,

85
00:04:33,090 --> 00:04:34,970
so would the neighbors.

86
00:04:34,970 --> 00:04:38,870
They basically have
to be told, it's OK.

87
00:04:38,870 --> 00:04:41,120
We're a dual-processor system.

88
00:04:41,120 --> 00:04:43,790
We're failing over the
other route processor.

89
00:04:43,790 --> 00:04:47,000
We can still forward
traffic with our line cards.

90
00:04:47,000 --> 00:04:49,050
Keep sending us traffic.

91
00:04:49,050 --> 00:04:51,360
Now, it, of course,
doesn't say all that,

92
00:04:51,360 --> 00:04:53,240
but that's the implied meaning.

93
00:04:53,240 --> 00:04:55,370
We're telling our
neighboring routers

94
00:04:55,370 --> 00:04:58,260
that we're still capable
of forwarding traffic

95
00:04:58,260 --> 00:05:00,770
so they know to keep
sending it to us.

96
00:05:00,770 --> 00:05:03,110
It also lets them
know that we'll

97
00:05:03,110 --> 00:05:06,650
be doing a soft rebuild
on the neighborship.

98
00:05:06,650 --> 00:05:09,560
In other words, we won't be
tearing down the neighborship

99
00:05:09,560 --> 00:05:11,150
and rebuilding it.

100
00:05:11,150 --> 00:05:13,850
We'll be rebuilding
the neighborship,

101
00:05:13,850 --> 00:05:18,050
resynchronizing our
databases, and then going back

102
00:05:18,050 --> 00:05:20,010
to normal operation.

103
00:05:20,010 --> 00:05:21,980
Now, of course, in
order for this to work,

104
00:05:21,980 --> 00:05:24,320
there's another requirement.

105
00:05:24,320 --> 00:05:27,650
That requirement is
quite simply that we have

106
00:05:27,650 --> 00:05:32,120
to have an NSF-aware neighbor.

107
00:05:32,120 --> 00:05:35,810
The neighbor has to
recognize that signal

108
00:05:35,810 --> 00:05:40,430
that the NSF-capable
router sent us.

109
00:05:40,430 --> 00:05:42,170
If we don't recognize
this signal,

110
00:05:42,170 --> 00:05:44,540
we wouldn't to keep
forwarding traffic

111
00:05:44,540 --> 00:05:48,090
to the NSF-capable router.

112
00:05:48,090 --> 00:05:51,470
Now, the key factor
here is these routers

113
00:05:51,470 --> 00:05:54,290
do not need dual processors.

114
00:05:54,290 --> 00:06:00,050
As far as I am aware, all
Cisco routers are NSF-aware.

115
00:06:00,050 --> 00:06:03,080
Again, they're not all
capable because they don't all

116
00:06:03,080 --> 00:06:07,790
have dual-route processors,
but they're all aware.

117
00:06:07,790 --> 00:06:10,280
Now, part of what this
aware router is going to do,

118
00:06:10,280 --> 00:06:12,980
as we've already
implied, is that it's

119
00:06:12,980 --> 00:06:16,850
going to preserve the
IS-IS link-state database

120
00:06:16,850 --> 00:06:18,470
and the routing table.

121
00:06:18,470 --> 00:06:21,080
That way, it continues
forwarding traffic,

122
00:06:21,080 --> 00:06:26,840
even though the other router
is failed over or failing over

123
00:06:26,840 --> 00:06:30,450
or we've lost the
neighborship essentially.

124
00:06:30,450 --> 00:06:32,360
And then we allow
that soft rebuild

125
00:06:32,360 --> 00:06:37,400
to happen on the neighborship
once the NSF-capable router

126
00:06:37,400 --> 00:06:39,480
comes back online.

127
00:06:39,480 --> 00:06:42,860
So it's not that the
NSF-aware router really

128
00:06:42,860 --> 00:06:45,890
has to do anything
spectacularly special here,

129
00:06:45,890 --> 00:06:48,500
but it has to be aware
of what's going on

130
00:06:48,500 --> 00:06:51,020
and what the process is.

131
00:06:51,020 --> 00:06:54,410
Now, unfortunately, there
is a third category here,

132
00:06:54,410 --> 00:06:59,310
and that is a
non-NSF aware router.

133
00:06:59,310 --> 00:07:04,460
And these quite simply just
do not participate in NSF.

134
00:07:04,460 --> 00:07:08,150
And if a route processor
failure happens,

135
00:07:08,150 --> 00:07:10,670
we're just going to have
to form a neighborship

136
00:07:10,670 --> 00:07:13,380
and come back up
just like normal.

137
00:07:13,380 --> 00:07:16,250
So non-NSF aware
routers aren't going

138
00:07:16,250 --> 00:07:19,110
to participate in this at all.

139
00:07:19,110 --> 00:07:22,310
Now, we did already mentioned
this, but just as a reminder

140
00:07:22,310 --> 00:07:25,190
that after the
recovery, everything

141
00:07:25,190 --> 00:07:27,230
is going to be reconverged.

142
00:07:27,230 --> 00:07:30,800
We're going to update any and
all tables as needed, mostly,

143
00:07:30,800 --> 00:07:33,350
of course, meaning the
link-state database

144
00:07:33,350 --> 00:07:36,470
and the routing table,
but these will be updated

145
00:07:36,470 --> 00:07:40,160
after everything
comes back online.

146
00:07:40,160 --> 00:07:45,470
The second feature, of course,
is NSR, or non-stop routing.

147
00:07:45,470 --> 00:07:47,880
This is a little bit different.

148
00:07:47,880 --> 00:07:54,950
It still allows failover and
process restart or even ISSU,

149
00:07:54,950 --> 00:07:58,040
which is our in-service
software update--

150
00:07:58,040 --> 00:08:00,500
but here's the
really cool part--

151
00:08:00,500 --> 00:08:04,160
without affecting neighbors.

152
00:08:04,160 --> 00:08:07,010
This doesn't involve
the neighbors at all.

153
00:08:07,010 --> 00:08:09,200
I don't care what
they're capable of,

154
00:08:09,200 --> 00:08:11,090
what they're not capable of.

155
00:08:11,090 --> 00:08:16,010
This is all done on the
router that supports NSR.

156
00:08:16,010 --> 00:08:18,170
The way this works
is it uses something

157
00:08:18,170 --> 00:08:21,200
called warm standby extensions.

158
00:08:21,200 --> 00:08:28,160
And we run a standby IS-IS
process on the standby RP.

159
00:08:28,160 --> 00:08:31,790
This is kept fully synchronized
with the active route

160
00:08:31,790 --> 00:08:32,900
processor.

161
00:08:32,900 --> 00:08:36,260
That way, if it
fails, the standby

162
00:08:36,260 --> 00:08:39,470
can take over almost instantly.

163
00:08:39,470 --> 00:08:43,070
And it's certainly faster than
any of our routing protocols

164
00:08:43,070 --> 00:08:45,170
would detect a neighbor failure.

165
00:08:45,170 --> 00:08:47,420
Since this is all
happening in-house

166
00:08:47,420 --> 00:08:49,730
and it happens so fast that
our neighbors don't even

167
00:08:49,730 --> 00:08:52,520
realize it, this
really does just

168
00:08:52,520 --> 00:08:57,020
alleviate the need for
non-stop forwarding.

169
00:08:57,020 --> 00:09:00,960
We don't need to be running
both of these at the same time.

170
00:09:00,960 --> 00:09:04,310
And what we're going to see is
that most of our newer devices

171
00:09:04,310 --> 00:09:06,890
are starting to support NSR.

172
00:09:06,890 --> 00:09:11,180
And therefore, we'll see that
non-stop forwarding isn't

173
00:09:11,180 --> 00:09:14,870
necessarily enabled
by default. Now,

174
00:09:14,870 --> 00:09:17,370
we're going to jump into the
command line in just a minute

175
00:09:17,370 --> 00:09:18,140
and look at this.

176
00:09:18,140 --> 00:09:21,530
And we'll see that non-stop
forwarding is not enabled

177
00:09:21,530 --> 00:09:23,670
by default on these devices.

178
00:09:23,670 --> 00:09:25,550
But I want to make
sure we're clear we

179
00:09:25,550 --> 00:09:27,330
understand what that means.

180
00:09:27,330 --> 00:09:32,240
It means that it's
not NSF-capable,

181
00:09:32,240 --> 00:09:35,810
NSF-aware is always on.

182
00:09:35,810 --> 00:09:39,200
If a neighbor tells us that
it's doing non-stop forwarding,

183
00:09:39,200 --> 00:09:42,300
we'll go, OK, and
that function works.

184
00:09:42,300 --> 00:09:47,007
We're talking about if this
device itself is NSF-capable.

185
00:09:47,007 --> 00:09:48,590
So we're going to
look at the topology

186
00:09:48,590 --> 00:09:51,547
just real quick just so we know
which devices we're looking at.

187
00:09:51,547 --> 00:09:53,630
And then we're going to
jump into the command line

188
00:09:53,630 --> 00:09:55,730
and see, again,
what little we can

189
00:09:55,730 --> 00:09:58,790
see about these technologies
without actually

190
00:09:58,790 --> 00:10:03,070
having dual-route processors.

191
00:10:03,070 --> 00:10:07,570
So for this skill, we'll
be using IS-IS Topology 1.

192
00:10:07,570 --> 00:10:10,510
And in this
particular video, just

193
00:10:10,510 --> 00:10:15,550
so we can see IOS
XR and IOS XE, we'll

194
00:10:15,550 --> 00:10:20,500
just be looking at the command
line on router 1 to get IOS XR

195
00:10:20,500 --> 00:10:24,250
and on router 5 to get IOS XE.

196
00:10:24,250 --> 00:10:27,970
So that said, let's jump into
the command line on router 1

197
00:10:27,970 --> 00:10:31,330
and take a look at what commands
we do have available to look

198
00:10:31,330 --> 00:10:34,990
at NSF and NSR.

199
00:10:34,990 --> 00:10:40,600
So if we start here on router 1
with just a show isis protocol,

200
00:10:40,600 --> 00:10:44,140
first thing we can see here
is that non-stop forwarding

201
00:10:44,140 --> 00:10:47,360
is disabled, as we mentioned.

202
00:10:47,360 --> 00:10:50,290
It is disabled by
default. And again, this

203
00:10:50,290 --> 00:10:55,420
is because non-stop routing
is enabled by default.

204
00:10:55,420 --> 00:10:58,010
This output doesn't
really show that.

205
00:10:58,010 --> 00:11:01,570
But if we do a show nsr
forwarding for the client

206
00:11:01,570 --> 00:11:05,470
trace process isis,
we can actually

207
00:11:05,470 --> 00:11:09,970
see that this is
enabled for isis1.

208
00:11:09,970 --> 00:11:13,000
So it's not the cleanest
output, but this

209
00:11:13,000 --> 00:11:16,630
is the best way that I'm
aware of to verify that NSR is

210
00:11:16,630 --> 00:11:18,940
actually enabled and operating.

211
00:11:18,940 --> 00:11:22,960
Again, it's a default, so
it's not generally shown.

212
00:11:22,960 --> 00:11:26,270
Now, we can enable non-stop
forwarding on this platform

213
00:11:26,270 --> 00:11:28,600
if we want to, but
again, the fact

214
00:11:28,600 --> 00:11:30,970
that it's running
non-stop routing

215
00:11:30,970 --> 00:11:33,110
negates the need for it.

216
00:11:33,110 --> 00:11:36,010
So that said, if you
did want to enable it,

217
00:11:36,010 --> 00:11:37,690
they're the same
commands that we're

218
00:11:37,690 --> 00:11:42,730
about to look at on
router 5 on IOS XE.

219
00:11:42,730 --> 00:11:45,310
So now, let's go
look at router 5.

220
00:11:45,310 --> 00:11:49,780
Again, if we do a show isis
nsf for non-stop forwarding,

221
00:11:49,780 --> 00:11:52,330
we see that non-stop
forwarding is also

222
00:11:52,330 --> 00:11:55,890
disabled on these
platforms as well.

223
00:11:55,890 --> 00:11:58,640
Now, this platform is not
going to be running non-stop

224
00:11:58,640 --> 00:12:03,020
routing because this platform
is not capable of having

225
00:12:03,020 --> 00:12:05,300
redundant route processors.

226
00:12:05,300 --> 00:12:07,760
However, we can
take a look at how

227
00:12:07,760 --> 00:12:11,190
we would turn on non-stop
forwarding if we wanted to.

228
00:12:11,190 --> 00:12:13,940
We simply go into
configuration mode,

229
00:12:13,940 --> 00:12:16,160
go into our router process.

230
00:12:16,160 --> 00:12:20,180
And under NSF, we can see
we have a few choices here.

231
00:12:20,180 --> 00:12:23,240
Of course, we can turn
on the Cisco method.

232
00:12:23,240 --> 00:12:25,940
We can turn on the IETF method.

233
00:12:25,940 --> 00:12:28,560
By the way, we can turn on both.

234
00:12:28,560 --> 00:12:33,000
We can also configure interface
properties or set the interval.

235
00:12:33,000 --> 00:12:35,240
So we're not going to
actually turn this on.

236
00:12:35,240 --> 00:12:37,950
We don't really have a need
to in our lab environment.

237
00:12:37,950 --> 00:12:42,660
But this is how we would
normally configure it.

238
00:12:42,660 --> 00:12:46,170
In this video, we took a
look at two technologies

239
00:12:46,170 --> 00:12:49,530
that we can use to help
with route processor

240
00:12:49,530 --> 00:12:51,690
failover or switchover.

241
00:12:51,690 --> 00:12:53,970
The first was
non-stop forwarding,

242
00:12:53,970 --> 00:12:58,080
which involved a cooperative
effort between our neighbors

243
00:12:58,080 --> 00:13:01,800
and the route that's having
the failover, where they really

244
00:13:01,800 --> 00:13:04,710
communicate with each other
and understand that we're going

245
00:13:04,710 --> 00:13:08,670
to keep forwarding packets until
the routing protocol comes back

246
00:13:08,670 --> 00:13:10,230
online again.

247
00:13:10,230 --> 00:13:13,830
The second choice, which
is also a newer choice,

248
00:13:13,830 --> 00:13:16,380
is non-stop routing.

249
00:13:16,380 --> 00:13:19,950
And in this case, the
standby route processor

250
00:13:19,950 --> 00:13:23,880
is kept in full sync with
the active route processor

251
00:13:23,880 --> 00:13:26,920
so that when a failover
does have to occur,

252
00:13:26,920 --> 00:13:30,660
it's so fast that the neighbors
don't even know it happened.

253
00:13:30,660 --> 00:13:33,420
It's almost instantaneous.

254
00:13:33,420 --> 00:13:36,270
I think it's 50 milliseconds
on most platforms

255
00:13:36,270 --> 00:13:39,540
that it'll switch over to
the standby route processor

256
00:13:39,540 --> 00:13:41,880
and just keep right
on forwarding traffic,

257
00:13:41,880 --> 00:13:44,100
keep right on running
the routing protocol just

258
00:13:44,100 --> 00:13:46,800
like nothing changed at all.

259
00:13:46,800 --> 00:13:49,080
I hope this has been
informative for you.

260
00:13:49,080 --> 00:13:52,190
And I'd like to thank
you for viewing.

261
00:13:52,190 --> 00:13:55,000