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

2
00:00:03,920 --> 00:00:08,340

3
00:00:08,340 --> 00:00:10,140
Of course, another
type of redundancy

4
00:00:10,140 --> 00:00:11,700
that we need to
be concerned with

5
00:00:11,700 --> 00:00:14,670
is redundancy for
the route processor.

6
00:00:14,670 --> 00:00:18,180
Most of our routers in a
service provider environment

7
00:00:18,180 --> 00:00:21,930
will have redundant route
processors or supervisor

8
00:00:21,930 --> 00:00:22,920
engines.

9
00:00:22,920 --> 00:00:25,680
The question comes
in, what happens

10
00:00:25,680 --> 00:00:29,310
when one of those supervisor
or route processors fails?

11
00:00:29,310 --> 00:00:31,650
We failover to the other one.

12
00:00:31,650 --> 00:00:36,510
Locally, our line cards can
continue forwarding traffic.

13
00:00:36,510 --> 00:00:38,880
But what about our neighbors?

14
00:00:38,880 --> 00:00:41,880
Will our neighbors still be able
to continue forwarding traffic

15
00:00:41,880 --> 00:00:43,050
to us?

16
00:00:43,050 --> 00:00:46,500
Will they even know that they
can continue forwarding traffic

17
00:00:46,500 --> 00:00:47,063
to us?

18
00:00:47,063 --> 00:00:48,480
That's what we're
going be talking

19
00:00:48,480 --> 00:00:55,840
about here with non-stop routing
or NSR and graceful restart.

20
00:00:55,840 --> 00:00:58,020
So let's go ahead and
jump in, and we'll

21
00:00:58,020 --> 00:01:01,780
talk about the attributes
of each one of these.

22
00:01:01,780 --> 00:01:04,950
So let's begin our discussion
of these two technologies

23
00:01:04,950 --> 00:01:07,530
with graceful restart.

24
00:01:07,530 --> 00:01:10,170
Now the idea behind
the graceful restart

25
00:01:10,170 --> 00:01:13,770
is to allow the recovery
of the control plane

26
00:01:13,770 --> 00:01:17,400
without actually
affecting the data plane.

27
00:01:17,400 --> 00:01:22,110
Now this works the same as
it does in routing protocols.

28
00:01:22,110 --> 00:01:25,650
In other words, LDP is using
the exact same mechanisms

29
00:01:25,650 --> 00:01:29,110
that things like
OSPF and IS-IS use,

30
00:01:29,110 --> 00:01:32,640
so this is really using
the same technologies.

31
00:01:32,640 --> 00:01:35,340
Now this may or may not
need to be enabled depending

32
00:01:35,340 --> 00:01:40,410
on the platform, so
graceful-restart on the LDP

33
00:01:40,410 --> 00:01:43,350
configuration for IOS XR.

34
00:01:43,350 --> 00:01:49,110
And if you're on IOS XE, it's
mpls ldp graceful-restart

35
00:01:49,110 --> 00:01:51,350
under global.

36
00:01:51,350 --> 00:01:55,130
Now there sort of two
parts to graceful restart,

37
00:01:55,130 --> 00:01:59,090
which by the way, is also
part of non-stop forwarding

38
00:01:59,090 --> 00:02:01,250
and stateful switchover.

39
00:02:01,250 --> 00:02:03,920
And the two parts are this.

40
00:02:03,920 --> 00:02:07,820
One device has to have
the dual route processors

41
00:02:07,820 --> 00:02:12,260
and is the one that's capable
of doing the switchover.

42
00:02:12,260 --> 00:02:14,360
That would be the
device that we would

43
00:02:14,360 --> 00:02:18,330
have to issue these commands
on to enable the feature.

44
00:02:18,330 --> 00:02:21,470
The other half of this
are the devices that,

45
00:02:21,470 --> 00:02:24,170
while they may or may
not be capable of doing

46
00:02:24,170 --> 00:02:27,920
graceful restart, but they
have to at least understand it.

47
00:02:27,920 --> 00:02:32,060
What that means is when they
get a graceful restart message

48
00:02:32,060 --> 00:02:35,240
from their neighbor, they
understand what it means,

49
00:02:35,240 --> 00:02:37,430
and they'll continue
forwarding the traffic,

50
00:02:37,430 --> 00:02:39,110
as we're about to
talk about here

51
00:02:39,110 --> 00:02:41,120
in the next couple of steps.

52
00:02:41,120 --> 00:02:44,360
But you don't have to
enable these features just

53
00:02:44,360 --> 00:02:46,010
to be the helper.

54
00:02:46,010 --> 00:02:48,210
You only have to
enable these features

55
00:02:48,210 --> 00:02:53,500
if you want to be the one
actually doing the switchover.

56
00:02:53,500 --> 00:02:56,890
So again, the idea is when
the capable device does

57
00:02:56,890 --> 00:03:02,590
the switchover, the
neighboring support LSRs that

58
00:03:02,590 --> 00:03:06,220
support the non-stop forwarding
and stateful switchover,

59
00:03:06,220 --> 00:03:09,430
they will continue to
forward the traffic

60
00:03:09,430 --> 00:03:12,620
to the device that's
doing the recovery.

61
00:03:12,620 --> 00:03:14,300
How does it do that?

62
00:03:14,300 --> 00:03:16,540
Well, first, traffic
is going to be

63
00:03:16,540 --> 00:03:20,620
forwarded using what's
called the last known good

64
00:03:20,620 --> 00:03:22,400
information.

65
00:03:22,400 --> 00:03:25,780
So I'm not going to be updating
my routing tables or anything

66
00:03:25,780 --> 00:03:28,930
like that because, technically,
our neighborship is

67
00:03:28,930 --> 00:03:30,310
sort of suspended.

68
00:03:30,310 --> 00:03:33,610
So in the case of LDP, I
wouldn't be learning new labels

69
00:03:33,610 --> 00:03:34,810
and things like that.

70
00:03:34,810 --> 00:03:39,320
I would just maintain my
database as I already know it.

71
00:03:39,320 --> 00:03:42,250
So not only does this allow
me to continue forwarding,

72
00:03:42,250 --> 00:03:45,760
but it also allows for
a much quicker recovery

73
00:03:45,760 --> 00:03:48,280
because I already
have the database.

74
00:03:48,280 --> 00:03:51,610
All I would be doing
is getting any changes

75
00:03:51,610 --> 00:03:54,820
from LDP that have happened
while the neighbor was

76
00:03:54,820 --> 00:03:56,320
switching over.

77
00:03:56,320 --> 00:04:01,060
Now, of course, we can't sit and
wait for the recovering device

78
00:04:01,060 --> 00:04:02,300
forever.

79
00:04:02,300 --> 00:04:04,930
What if the switch
over to the other route

80
00:04:04,930 --> 00:04:09,050
processor on our neighboring
device actually fails?

81
00:04:09,050 --> 00:04:13,420
So if it does not recover
in the allocated time,

82
00:04:13,420 --> 00:04:15,460
well, it's going to be removed.

83
00:04:15,460 --> 00:04:17,890
In other words, we'll just
take the neighborship down

84
00:04:17,890 --> 00:04:19,959
like we normally would.

85
00:04:19,959 --> 00:04:23,980
If the device does
reconnect, we will again

86
00:04:23,980 --> 00:04:26,620
continue using the
stale info, which

87
00:04:26,620 --> 00:04:28,850
is the last known
good configuration.

88
00:04:28,850 --> 00:04:30,040
That's what it is.

89
00:04:30,040 --> 00:04:33,610
But we'll continue using
that while we resynchronize

90
00:04:33,610 --> 00:04:35,980
the database and
learn about anything

91
00:04:35,980 --> 00:04:39,160
that changed while our
neighborship was effectively

92
00:04:39,160 --> 00:04:40,540
suspended.

93
00:04:40,540 --> 00:04:43,820
So overall, this is a
very effective system.

94
00:04:43,820 --> 00:04:46,250
This has been around
for quite some time.

95
00:04:46,250 --> 00:04:48,940
And it's a tried
and true technology

96
00:04:48,940 --> 00:04:51,640
that we use again for
routing protocols,

97
00:04:51,640 --> 00:04:54,740
and LDP supports it as well.

98
00:04:54,740 --> 00:04:56,590
But here's the thing.

99
00:04:56,590 --> 00:04:59,320
A lot of our newer
devices support

100
00:04:59,320 --> 00:05:02,980
NSR, which is Non-Stop Routing.

101
00:05:02,980 --> 00:05:08,830
Non-stop routing handles the
entire process internally.

102
00:05:08,830 --> 00:05:14,440
The neighbors never even know
that a switchover occurred.

103
00:05:14,440 --> 00:05:17,350
If the neighbors never know
that a switchover occurred,

104
00:05:17,350 --> 00:05:20,980
then there's no need
for a graceful restart.

105
00:05:20,980 --> 00:05:23,930
See, these are sort
of mutually exclusive.

106
00:05:23,930 --> 00:05:26,380
You can certainly
configure both of them.

107
00:05:26,380 --> 00:05:27,790
Don't get me wrong.

108
00:05:27,790 --> 00:05:30,220
But non-stop routing
pretty much makes

109
00:05:30,220 --> 00:05:35,140
non-stop forwarding or
graceful restart unnecessary.

110
00:05:35,140 --> 00:05:40,390
Now NSR can be enabled
simply typing nsr

111
00:05:40,390 --> 00:05:45,340
under LDP configuration if your
particular platform doesn't

112
00:05:45,340 --> 00:05:49,150
have it enabled by
default. Some platforms do.

113
00:05:49,150 --> 00:05:51,520
Some platforms do
not, so you'll want

114
00:05:51,520 --> 00:05:54,670
to verify with your
configuration guides

115
00:05:54,670 --> 00:05:56,320
to see if you need
to enable this

116
00:05:56,320 --> 00:05:58,750
on your particular platform.

117
00:05:58,750 --> 00:06:02,710
Of these two, clearly,
we would prefer NSR.

118
00:06:02,710 --> 00:06:04,550
It's the newer technology.

119
00:06:04,550 --> 00:06:07,180
However, if your
devices only support

120
00:06:07,180 --> 00:06:09,640
graceful restarts /
non-stop forwarding

121
00:06:09,640 --> 00:06:13,210
/ stateful switchover,
well, again, that's

122
00:06:13,210 --> 00:06:14,770
a tried and true
technology that's

123
00:06:14,770 --> 00:06:16,870
been around for
a very long time,

124
00:06:16,870 --> 00:06:20,350
and it also works very well.

125
00:06:20,350 --> 00:06:24,060
So in this video, we talked
about graceful restart

126
00:06:24,060 --> 00:06:26,610
and non-stop routing.

127
00:06:26,610 --> 00:06:29,200
Graceful restart
involves the neighbors.

128
00:06:29,200 --> 00:06:30,960
The neighbors have
to understand it.

129
00:06:30,960 --> 00:06:34,290
We basically tell them
we're doing a switchover,

130
00:06:34,290 --> 00:06:36,780
but that's OK, go ahead
and keep forwarding traffic

131
00:06:36,780 --> 00:06:40,170
to me using the last
known good information.

132
00:06:40,170 --> 00:06:43,270
And then when the
neighborship comes back up,

133
00:06:43,270 --> 00:06:46,710
we use that old information
and then just build on it

134
00:06:46,710 --> 00:06:49,620
and refresh the information
can make our database up

135
00:06:49,620 --> 00:06:51,210
to date much quicker.

136
00:06:51,210 --> 00:06:55,590
In the case of non-stop routing,
it's all handled locally

137
00:06:55,590 --> 00:06:58,080
so quickly the
neighbors don't even

138
00:06:58,080 --> 00:06:59,950
know the neighborship went down.

139
00:06:59,950 --> 00:07:04,050
Therefore, there's no need
for non-stop forwarding

140
00:07:04,050 --> 00:07:07,320
to even exist when we're
doing non-stop routing.

141
00:07:07,320 --> 00:07:09,510
We certainly don't
have to enable it.

142
00:07:09,510 --> 00:07:11,310
Can we enable both?

143
00:07:11,310 --> 00:07:13,560
Yes, on most platforms
that I've seen.

144
00:07:13,560 --> 00:07:15,600
But again, with
non-stop routing,

145
00:07:15,600 --> 00:07:17,490
there's really no need.

146
00:07:17,490 --> 00:07:20,460
Something else that we might
need to be concerned about

147
00:07:20,460 --> 00:07:24,990
is in the event of other types
of failures, maybe a router

148
00:07:24,990 --> 00:07:27,840
reloads or something
along those lines.

149
00:07:27,840 --> 00:07:32,310
What would happen if LDP
came up and synchronized

150
00:07:32,310 --> 00:07:34,950
faster than our IGP did?

151
00:07:34,950 --> 00:07:37,980
We might have labels and
try to do label forwarding

152
00:07:37,980 --> 00:07:40,800
before they're actually
valid in our routing table

153
00:07:40,800 --> 00:07:42,670
from our routing protocols.

154
00:07:42,670 --> 00:07:45,120
So that's something that we
may want to take a look at,

155
00:07:45,120 --> 00:07:47,650
and that's exactly what
we're going to do next.

156
00:07:47,650 --> 00:07:50,910
Until then, I hope this has
been informative for you,

157
00:07:50,910 --> 00:07:53,960
and I'd like to thank
you for viewing.

158
00:07:53,960 --> 00:07:57,000