WEBVTT

1
00:00.000 --> 00:09.000
So let's begin our journey by looking at modifying routing protocol timers and

2
00:09.000 --> 00:10.240
implementing

3
00:10.240 --> 00:14.280
bidirectional forwarding detection or BFD.

4
00:14.280 --> 00:18.560
Both of these technologies have the same sort of idea in mind.

5
00:18.560 --> 00:24.960
To speed up how quickly we detect a failure and therefore can converge and fix

6
00:24.960 --> 00:26.100
that problem

7
00:26.100 --> 00:28.280
by using an alternate path.

8
00:28.280 --> 00:32.280
So what we're going to do here is we're going to jump in and first look at our
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

8
00:28.280 --> 00:32.280
So what we're going to do here is we're going to jump in and first look at our

9
00:32.280 --> 00:32.920
topology

10
00:32.920 --> 00:34.880
so that we know what we're working with.

11
00:34.880 --> 00:39.360
We'll discuss our strategy and then of course let's jump into the command line,

12
00:39.360 --> 00:39.760
get this

13
00:39.760 --> 00:44.130
working so we can actually see the difference in convergence speeds between the

14
00:44.130 --> 00:44.800
different

15
00:44.800 --> 00:46.280
technologies.

16
00:46.280 --> 00:49.240
Let's get started.

17
00:49.240 --> 00:54.000
So this is the topology that we're going to be using throughout this skill.

18
00:54.000 --> 00:58.200
And as we begin there's a couple things we want to get out of the way.

19
00:58.200 --> 01:03.640
First the right side of this diagram is basically going to be used to represent
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

19
00:58.200 --> 01:03.640
First the right side of this diagram is basically going to be used to represent

20
01:03.640 --> 01:05.520
the cloud providers.

21
01:05.520 --> 01:09.920
So we're not going to be doing much on the right side except those things that

22
01:09.920 --> 01:10.360
we need

23
01:10.360 --> 01:11.360
to.

24
01:11.360 --> 01:16.640
But ultimately we'll be looking at connecting to this server over here as our

25
01:16.640 --> 01:17.640
end resource

26
01:17.640 --> 01:23.720
that we're trying to provide redundancy and performance towards that server.

27
01:23.720 --> 01:27.780
Also be aware that for our routing protocol here in the core we're going to be

28
01:27.780 --> 01:28.280
running

29
01:28.280 --> 01:30.000
OSPF.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

30
01:30.000 --> 01:36.280
Now of course we could use any routing protocol here OSPF and BGP being the

31
01:36.280 --> 01:37.600
most popular.

32
01:37.600 --> 01:41.720
But we're going to focus here a bit on OSPF.

33
01:41.720 --> 01:46.150
Also note that for right now we have two subnets we're going to be working on

34
01:46.150 --> 01:49.640
the 10.10.10.0/24

35
01:49.640 --> 02:00.680
We also of course have WAN links here in the middle 172.16.10.0 and 172.16.20.0
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

35
01:49.640 --> 02:00.680
We also of course have WAN links here in the middle 172.16.10.0 and 172.16.20.0

36
02:00.680 --> 02:04.200
.

37
02:04.200 --> 02:10.280
These are acting as the WAN links and as such they also have these WAN em

38
02:10.280 --> 02:11.760
ulators on them

39
02:11.760 --> 02:12.760
here.

40
02:12.760 --> 02:19.960
And the purpose of these is to be able to introduce problems into the WAN.

41
02:19.960 --> 02:24.120
Things like latency, jitter, packet loss.

42
02:24.120 --> 02:28.120
That way we can emulate our WAN actually having issues.

43
02:28.120 --> 02:32.510
Now as we jump in and get started we are going to have some things already
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

43
02:28.120 --> 02:32.510
Now as we jump in and get started we are going to have some things already

44
02:32.510 --> 02:33.400
configured.

45
02:33.400 --> 02:36.640
OSPF is already configured.

46
02:36.640 --> 02:43.270
So right now between router 1 and router 2 over here on the customer side we're

47
02:43.270 --> 02:43.640
already

48
02:43.640 --> 02:49.280
running a virtual router which is at the IP address dot 1.

49
02:49.280 --> 02:56.430
And this is running between like we said R1 and R2 and this is currently using

50
02:56.430 --> 02:57.040
VRRP.

51
02:57.040 --> 03:01.240
So as per usual I would encourage you to keep this diagram handy as we move
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

51
02:57.040 --> 03:01.240
So as per usual I would encourage you to keep this diagram handy as we move

52
03:01.240 --> 03:01.960
throughout

53
03:01.960 --> 03:07.010
the skill I'll bring it back up to reference things as we're building them but

54
03:07.010 --> 03:07.560
in this

55
03:07.560 --> 03:12.850
particular video we're going to be focusing on timers and running bidirectional

56
03:12.850 --> 03:13.760
forwarding

57
03:13.760 --> 03:15.080
detection.

58
03:15.080 --> 03:21.480
And of course for those items we're going to be focusing on the timers for OSPF

59
03:21.480 --> 03:21.520
and

60
03:21.520 --> 03:27.620
of course for BFD we're going to be taking a look at running this on the two W

61
03:27.620 --> 03:28.480
AN links.

62
03:28.480 --> 03:33.880
What this is going to do for us of course is greatly decrease the amount of
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

62
03:28.480 --> 03:33.880
What this is going to do for us of course is greatly decrease the amount of

63
03:33.880 --> 03:35.040
time it takes

64
03:35.040 --> 03:43.500
R1 and R2 to realize that there is a failure on the WAN and therefore to recon

65
03:43.500 --> 03:44.800
verge OSPF.

66
03:44.800 --> 03:51.110
Now for the BFD portion be aware that routers 3 and 4 have already been

67
03:51.110 --> 03:52.760
configured to run

68
03:52.760 --> 03:59.840
BFD so again we'll be focusing on the customer side router 1 and router 2.

69
03:59.840 --> 04:02.480
So now that we have a game plan together and an overall idea of what we're
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

69
03:59.840 --> 04:02.480
So now that we have a game plan together and an overall idea of what we're

70
04:02.480 --> 04:03.680
going to build

71
04:03.680 --> 04:07.240
let's go ahead and jump in we'll still do a little bit of exploring on the

72
04:07.240 --> 04:08.440
command line

73
04:08.440 --> 04:12.080
let's begin with router 1.

74
04:12.080 --> 04:14.840
So actually the first thing we're going to want to do is we're going to go into

75
04:14.840 --> 04:15.280
configuration

76
04:15.280 --> 04:20.230
mode and we're going to turn on logging for the console because we're going to

77
04:20.230 --> 04:20.760
want to

78
04:20.760 --> 04:25.260
see console messages as we're going through this and I do have the logging

79
04:25.260 --> 04:26.000
turned off

80
04:26.000 --> 04:28.240
in the baseline configuration.

81
04:28.240 --> 04:31.930
So we'll turn this back on just here on router 1 and then let's look at some of
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

81
04:28.240 --> 04:31.930
So we'll turn this back on just here on router 1 and then let's look at some of

82
04:31.930 --> 04:32.400
the things

83
04:32.400 --> 04:34.400
that are already configured.

84
04:34.400 --> 04:38.930
First if we look at the running configuration for gigabit 1 which is facing the

85
04:38.930 --> 04:39.480
client

86
04:39.480 --> 04:46.300
side we see a couple things here first we've turned off IP redirects and IP

87
04:46.300 --> 04:48.240
proxy art.

88
04:48.240 --> 04:53.650
Most of these can actually help the client keep connectivity to the other side

89
04:53.650 --> 04:54.160
so these

90
04:54.160 --> 04:58.480
are things we would probably normally want to leave on in most environments.

91
04:58.480 --> 05:03.030
I've turned them off simply so we can focus more on how these other
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

91
04:58.480 --> 05:03.030
I've turned them off simply so we can focus more on how these other

92
05:03.030 --> 05:04.440
technologies work

93
05:04.440 --> 05:07.360
without having to worry about these other features.

94
05:07.360 --> 05:12.480
Also note that I've already changed the OSPF hello and dead intervals.

95
05:12.480 --> 05:15.780
Now we're going to talk about those in just a moment but notice that they're

96
05:15.780 --> 05:16.240
already

97
05:16.240 --> 05:20.760
set to one for the hello and four for the dead.

98
05:20.760 --> 05:25.220
Here we also see that VRRP is also already configured and the only thing that's

99
05:25.220 --> 05:25.680
really

100
05:25.680 --> 05:32.280
set different from the default is the priority here on router 1 is set to 110.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

100
05:25.680 --> 05:32.280
set different from the default is the priority here on router 1 is set to 110.

101
05:32.280 --> 05:36.760
If we do the same thing but look at our WAN interface gigabit 2 we'll see this

102
05:36.760 --> 05:37.240
is very

103
05:37.240 --> 05:38.840
similar.

104
05:38.840 --> 05:43.550
Here we've also set the OSPF timers and we've set it to OSPF network type point

105
05:43.550 --> 05:43.800
to

106
05:43.800 --> 05:48.760
point but here of course we do not have VRRP enabled.

107
05:48.760 --> 05:54.930
If we do a show VRRP here on router 1 we see that because the priority is 110

108
05:54.930 --> 05:55.480
this side

109
05:55.480 --> 06:02.750
is currently the master which is in charge of the 10.10.10.1 virtual IP address
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

109
05:55.480 --> 06:02.750
is currently the master which is in charge of the 10.10.10.1 virtual IP address

110
06:02.750 --> 06:02.760
.

111
06:02.760 --> 06:07.320
So this is currently the active router for VRRP.

112
06:07.320 --> 06:12.880
If we take a look at router 2 if we look here at the configuration for gigabit

113
06:12.880 --> 06:13.080
1 we see

114
06:13.080 --> 06:18.040
that this is configured the same way except there is no VRRP priority set

115
06:18.040 --> 06:19.000
therefore it's

116
06:19.000 --> 06:22.040
going to be at the default of 100.

117
06:22.040 --> 06:26.540
If we do a show VRRP we can see that the local priority is 100 and that the

118
06:26.540 --> 06:27.840
master router

119
06:27.840 --> 06:32.920
being router 1 has its priority set to 110.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

119
06:27.840 --> 06:32.920
being router 1 has its priority set to 110.

120
06:32.920 --> 06:37.530
If we look at the WAN interface we see that this is also configured the same

121
06:37.530 --> 06:38.080
way.

122
06:38.080 --> 06:42.310
So since router 1 is the active router right now if we were to go over to work

123
06:42.310 --> 06:44.440
station 1

124
06:44.440 --> 06:50.770
and we were to do a trace route over to the 10.10.2010 which is our server

125
06:50.770 --> 06:51.320
notice we get

126
06:51.320 --> 06:54.160
a few timeouts there because of the ARPs.

127
06:54.160 --> 06:57.320
Let's go ahead and do it again just we have a nice clean output.

128
06:57.320 --> 07:01.480
Here we can see that it is in fact going to router 1 first.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

128
06:57.320 --> 07:01.480
Here we can see that it is in fact going to router 1 first.

129
07:01.480 --> 07:10.260
Remember that router 1 is actually the 10.10.10.2 because VRRP is at 10.1.1.1.

130
07:10.260 --> 07:20.040
So router 1 is actually 2 router 2 is actually 3 on the 10.10.10.0/24 subnet.

131
07:20.040 --> 07:24.730
Now what we're going to do is we're going to test the current failover times

132
07:24.730 --> 07:25.360
and note

133
07:25.360 --> 07:32.160
as we do we have already sped up the OSPF timers from their defaults.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

133
07:25.360 --> 07:32.160
as we do we have already sped up the OSPF timers from their defaults.

134
07:32.160 --> 07:38.650
Right now our dead time is 4 seconds and depending on the interface type with O

135
07:38.650 --> 07:39.320
SPF that could

136
07:39.320 --> 07:43.920
be normally either 40 or 120 seconds.

137
07:43.920 --> 07:49.170
So we've already sped this up but let's do a test and see what happens when we

138
07:49.170 --> 07:49.600
fail

139
07:49.600 --> 07:53.280
over the way things are right now.

140
07:53.280 --> 07:57.650
First thing we're going to do here on router 3 is we're going to get this ready

141
07:57.650 --> 07:58.040
to shut

142
07:58.040 --> 08:03.160
down the interface to create a WAN failure but we're not going to hit enter.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

142
07:58.040 --> 08:03.160
down the interface to create a WAN failure but we're not going to hit enter.

143
08:03.160 --> 08:06.040
This is just so we can do it as quickly as possible.

144
08:06.040 --> 08:12.040
Now let's go to workstation 1 and workstation 2 and do a continuous ping.

145
08:12.040 --> 08:15.800
Now just so we can do this quickly I've already entered the ping commands on

146
08:15.800 --> 08:17.640
both devices.

147
08:17.640 --> 08:22.880
Keep in mind that workstation 2 is actually a Cisco router.

148
08:22.880 --> 08:28.320
I'm doing this because for this test the ping output on the Cisco router is

149
08:28.320 --> 08:28.720
going to be

150
08:28.720 --> 08:33.590
a little bit easier to see what happens than it is here on this Linux work
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

150
08:28.720 --> 08:33.590
a little bit easier to see what happens than it is here on this Linux work

151
08:33.590 --> 08:34.400
station.

152
08:34.400 --> 08:36.760
But let's go ahead and do our test.

153
08:36.760 --> 08:45.160
So we'll start our pings.

154
08:45.160 --> 08:49.440
We'll shut down our interface and we'll stop our pings.

155
08:49.440 --> 08:55.530
So since I stopped the pings here on workstation 1 last we can see right here

156
08:55.530 --> 08:56.120
where there was

157
08:56.120 --> 08:57.720
a momentary timeout.

158
08:57.720 --> 09:01.080
Now we're doing a timeout of 1 second here.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

158
08:57.720 --> 09:01.080
Now we're doing a timeout of 1 second here.

159
09:01.080 --> 09:04.880
Now again depending on exactly how the timers fall this would have been

160
09:04.880 --> 09:06.320
somewhere between

161
09:06.320 --> 09:09.520
3 to 4 seconds for the failover.

162
09:09.520 --> 09:13.240
We're seeing that we actually lost two complete pings.

163
09:13.240 --> 09:18.200
This is actually a little bit harder to see on workstation 1 but let's take a

164
09:18.200 --> 09:18.880
look.

165
09:18.880 --> 09:22.900
What we have to do on the workstation here is actually scroll up a little bit

166
09:22.900 --> 09:23.440
and look

167
09:23.440 --> 09:26.280
for the missing sequence numbers.

168
09:26.280 --> 09:32.760
So you can see here that between 88 and 93 we missed a lot of sequence numbers.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

168
09:26.280 --> 09:32.760
So you can see here that between 88 and 93 we missed a lot of sequence numbers.

169
09:32.760 --> 09:37.140
Now the timeouts here on Linux are a little bit different so this is going to

170
09:37.140 --> 09:37.880
represent

171
09:37.880 --> 09:42.200
again right around a 3 to 4 second failover.

172
09:42.200 --> 09:44.960
So this is where we're at right now.

173
09:44.960 --> 09:49.160
And again this is what the OSPF timers already changed.

174
09:49.160 --> 09:51.760
Well let's go back over to router 1.

175
09:51.760 --> 09:56.120
Now what we see here on router 1 since we do have our console messages on first

176
09:56.120 --> 09:56.560
we see

177
09:56.560 --> 09:59.800
where OSPF did in fact go down.

178
09:59.800 --> 10:04.740
Also note here that it is back up because I did go back over to router 3 and
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

178
09:59.800 --> 10:04.740
Also note here that it is back up because I did go back over to router 3 and

179
10:04.740 --> 10:05.200
bring our

180
10:05.200 --> 10:07.880
WAN connection back online.

181
10:07.880 --> 10:09.960
So we're right back to the beginning now.

182
10:09.960 --> 10:14.850
And what we could do is we could go into our interface, gigabit 2 interface and

183
10:14.850 --> 10:15.320
we could

184
10:15.320 --> 10:21.930
say IPOSPF dead interval and remember this is currently set to 4 but there's

185
10:21.930 --> 10:22.760
actually

186
10:22.760 --> 10:27.080
a special keyword on here which is minimal.

187
10:27.080 --> 10:31.950
The reason this is important is because you can say minimal and as you can see
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

187
10:27.080 --> 10:31.950
The reason this is important is because you can say minimal and as you can see

188
10:31.950 --> 10:32.600
from the

189
10:32.600 --> 10:39.280
description that means 1 second but then you can set the hello multiplier.

190
10:39.280 --> 10:44.120
So I could say for example hello multiplier 4.

191
10:44.120 --> 10:49.380
Now if I hit enter on this my OSPF neighborhood with router 3 is going to go

192
10:49.380 --> 10:50.440
down because

193
10:50.440 --> 10:54.680
of course I haven't set those timers over on router 3.

194
10:54.680 --> 11:01.620
However the important thing here is if I do a show IPOSPF interface 4 gigabit 2
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

194
10:54.680 --> 11:01.620
However the important thing here is if I do a show IPOSPF interface 4 gigabit 2

195
11:01.620 --> 11:02.200
notice

196
11:02.200 --> 11:09.520
that the hello timer is now set to 250 milliseconds with a dead interval of 1.

197
11:09.520 --> 11:14.930
The reason that's important is if I try to set the hello interval directly

198
11:14.930 --> 11:15.560
notice the

199
11:15.560 --> 11:19.640
lowest you can set it is to 1 second.

200
11:19.640 --> 11:24.360
So the only way to get the millisecond hello timers with OSPF at least in the

201
11:24.360 --> 11:25.920
current code

202
11:25.920 --> 11:32.100
is to use that dead interval minimal command and then set the hello multiplier
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

202
11:25.920 --> 11:32.100
is to use that dead interval minimal command and then set the hello multiplier

203
11:32.100 --> 11:33.040
to however

204
11:33.040 --> 11:36.440
many hellos you want in that one second.

205
11:36.440 --> 11:41.100
Now we're not going to actually leave this set this way simply because if we do

206
11:41.100 --> 11:41.480
it's

207
11:41.480 --> 11:46.480
going to be really difficult to see BFD in action.

208
11:46.480 --> 11:52.110
So as much as I would love to fix this using OSPF timers the fastest we can

209
11:52.110 --> 11:52.880
make OSPF

210
11:52.880 --> 11:59.730
converge is with this one second dead interval but with BFD we can make it even

211
11:59.730 --> 12:00.720
faster and
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

211
11:59.730 --> 12:00.720
faster and

212
12:00.720 --> 12:02.800
that's what we want to configure.

213
12:02.800 --> 12:07.770
So for now we're simply going to take this out set the hello interval back to

214
12:07.770 --> 12:08.720
one second.

215
12:08.720 --> 12:13.370
So we see here as soon as we set the hello interval to one the OSPF adjacency

216
12:13.370 --> 12:14.480
automatically

217
12:14.480 --> 12:19.740
came up and the reason for that if we look at the showroom for our interface

218
12:19.740 --> 12:20.240
notice we've

219
12:20.240 --> 12:25.200
only set the hello interval here not the dead but remember that the default

220
12:25.200 --> 12:26.240
dead interval

221
12:26.240 --> 12:28.720
is four times the hello.

222
12:28.720 --> 12:33.200
So we actually don't have to explicitly set the dead interval here.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

222
12:28.720 --> 12:33.200
So we actually don't have to explicitly set the dead interval here.

223
12:33.200 --> 12:38.440
If we look at the OSPF interface again we see here that the hello is one the

224
12:38.440 --> 12:38.840
dead is

225
12:38.840 --> 12:42.880
four and our neighborship is back up.

226
12:42.880 --> 12:47.600
So in this video we spent just a few moments exploring our environment taking a

227
12:47.600 --> 12:48.120
look at

228
12:48.120 --> 12:54.060
how things are configured and we did a failover test with our OSPF timers set

229
12:54.060 --> 12:54.880
to detect the

230
12:54.880 --> 12:57.840
failure in four seconds.

231
12:57.840 --> 13:03.960
In the next video let's enable BFD and get BFD up and running so this failover
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

231
12:57.840 --> 13:03.960
In the next video let's enable BFD and get BFD up and running so this failover

232
13:03.960 --> 13:04.800
happens

233
13:04.800 --> 13:05.720
even faster.