WEBVTT

1
00:00.000 --> 00:08.740
So, just a quick reminder here, as we jump in, this is part two of a two-part

2
00:08.740 --> 00:09.480
skill.

3
00:09.480 --> 00:13.220
So if you have not yet reviewed the first part, I would encourage you to go

4
00:13.220 --> 00:13.780
back and

5
00:13.780 --> 00:16.940
watch that before jumping in here.

6
00:16.940 --> 00:22.890
But that said, in this video, we're now going to jump in and look at IP SLA or

7
00:22.890 --> 00:23.980
Service Level

8
00:23.980 --> 00:24.980
Agreement.

9
00:24.980 --> 00:29.850
Now, your first reaction, especially once you see what this is for, is why do

10
00:29.850 --> 00:30.380
we need
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

10
00:29.850 --> 00:30.380
we need

11
00:30.380 --> 00:35.540
this if we just discussed BFD or bidirectional forwarding detection?

12
00:35.540 --> 00:39.080
Well, the fact of the matter is, there's a few reasons.

13
00:39.080 --> 00:44.570
The first reason is, we may not be able to run BFD with the other side of the

14
00:44.570 --> 00:45.820
connection.

15
00:45.820 --> 00:50.420
If our neighboring cloud provider doesn't support BFD, then that's not going to

16
00:50.420 --> 00:50.700
be

17
00:50.700 --> 00:52.180
an option.

18
00:52.180 --> 00:56.530
Because of the time of this recording, the only cloud provider that publicly

19
00:56.530 --> 00:56.940
says that

20
00:56.940 --> 01:02.660
they support BFD is actually AWS, Amazon's service.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

20
00:56.940 --> 01:02.660
they support BFD is actually AWS, Amazon's service.

21
01:02.660 --> 01:06.810
So the other ones, although we still might be able to use it if we deploy our

22
01:06.810 --> 01:07.540
own router

23
01:07.540 --> 01:13.030
into their cloud and then run BFD between our on-prem router and the cloud

24
01:13.030 --> 01:13.780
router,

25
01:13.780 --> 01:15.060
we could still use it.

26
01:15.060 --> 01:19.940
I'm just saying that the provider itself doesn't necessarily offer that service

27
01:19.940 --> 01:20.060
.

28
01:20.060 --> 01:24.660
There's something like IP SLA, particularly if we're doing something as simple

29
01:24.660 --> 01:25.340
as a ping

30
01:25.340 --> 01:28.660
test, may be a better solution.

31
01:28.660 --> 01:33.250
The other reason is, we might need this for reporting reasons, to make sure
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

31
01:28.660 --> 01:33.250
The other reason is, we might need this for reporting reasons, to make sure

32
01:33.250 --> 01:33.820
that, you

33
01:33.820 --> 01:37.860
know, the service provider is meeting their service level agreement.

34
01:37.860 --> 01:41.590
That is, after all, at the end of the day, what this technology was actually

35
01:41.590 --> 01:42.180
developed

36
01:42.180 --> 01:43.420
for.

37
01:43.420 --> 01:48.280
And the third reason is, it's going to be easier if you remember from our BFD

38
01:48.280 --> 01:49.260
section,

39
01:49.260 --> 01:54.900
one of our main problems was that VRRP or our first Hot Redonancy protocol didn

40
01:54.900 --> 01:55.380
't fail

41
01:55.380 --> 02:01.420
over, even though OSPF converged and said that the win link was down.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

41
01:55.380 --> 02:01.420
over, even though OSPF converged and said that the win link was down.

42
02:01.420 --> 02:08.020
Well, we can technically monitor BFD and have it switch over using something

43
02:08.020 --> 02:08.700
called

44
02:08.700 --> 02:13.260
EEM or embedded event manager, which we're going to be talking about further

45
02:13.260 --> 02:13.900
down here

46
02:13.900 --> 02:15.140
in this skill.

47
02:15.140 --> 02:21.100
So it can be done, but it's simply going to be easier to react with IP SLA

48
02:21.100 --> 02:22.340
because IP

49
02:22.340 --> 02:27.220
SLA can trigger a tracked object, which we'll see in the next video.

50
02:27.220 --> 02:34.040
And then that can be used to react to something such as switching VRRP over or
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

50
02:27.220 --> 02:34.040
And then that can be used to react to something such as switching VRRP over or

51
02:34.040 --> 02:35.340
maybe adding

52
02:35.340 --> 02:38.620
or removing a static route from our routing table.

53
02:38.620 --> 02:42.980
There's a few things we can do in response to tracked objects.

54
02:42.980 --> 02:49.190
So all of that said, let's jump in here and take a look at IP SLA and using it

55
02:49.190 --> 02:50.260
to monitor

56
02:50.260 --> 02:53.940
this win link.

57
02:53.940 --> 02:57.930
So as we begin, let's jump in with a quick reminder of what we have going on

58
02:57.930 --> 02:58.540
right now

59
02:58.540 --> 03:00.580
in our topology.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

59
02:58.540 --> 03:00.580
in our topology.

60
03:00.580 --> 03:06.680
Right now, we currently have BFD running on the link between our one and our

61
03:06.680 --> 03:07.500
three, as

62
03:07.500 --> 03:10.540
well as our two and our four.

63
03:10.540 --> 03:14.740
And one of the things we're going to have to do in this lab to really be able

64
03:14.740 --> 03:15.180
to see

65
03:15.180 --> 03:21.590
how IPS LA works is we're actually going to be turning off BFD at least on this

66
03:21.590 --> 03:22.620
interface

67
03:22.620 --> 03:25.220
between our one and our three.

68
03:25.220 --> 03:29.850
Because as we mentioned during the introduction, BFD is going to respond to

69
03:29.850 --> 03:30.980
what we're going
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

69
03:29.850 --> 03:30.980
what we're going

70
03:30.980 --> 03:33.380
to do to this WAN circuit.

71
03:33.380 --> 03:37.270
And what I mean by that is we're going to be using this WAN emulator right here

72
03:37.270 --> 03:37.860
to actually

73
03:37.860 --> 03:43.120
introduce some delay and jitter and so on into this WAN link to cause issues

74
03:43.120 --> 03:43.980
that we're

75
03:43.980 --> 03:46.900
going to monitor with IPS LA.

76
03:46.900 --> 03:51.400
We don't want BFD to be responding honestly, just because it's going to cause a

77
03:51.400 --> 03:51.860
lot of

78
03:51.860 --> 03:53.460
flapping.

79
03:53.460 --> 03:58.420
We'll actually leave it on as we begin, just so you can see the problem.

80
03:58.420 --> 04:02.860
But you'll see very quickly why we're going to have to turn off BFD in order to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

80
03:58.420 --> 04:02.860
But you'll see very quickly why we're going to have to turn off BFD in order to

81
04:02.860 --> 04:03.340
focus

82
04:03.340 --> 04:05.540
on IPS LA.

83
04:05.540 --> 04:09.050
With that said, with our IPS LA, what we're going to be doing is we're going to

84
04:09.050 --> 04:09.620
be running

85
04:09.620 --> 04:15.980
probes between our one and our three to monitor the quality of this link.

86
04:15.980 --> 04:18.140
So that's going to be our goal here.

87
04:18.140 --> 04:20.260
Let's go ahead and jump in.

88
04:20.260 --> 04:23.540
We'll start off on router one.

89
04:23.540 --> 04:27.140
So let's begin with just some real quick verification.

90
04:27.140 --> 04:29.860
Let's do a show IPOS PF neighbor.

91
04:29.860 --> 04:34.140
We see that we do in fact having neighborship up with router three and locally
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

91
04:29.860 --> 04:34.140
We see that we do in fact having neighborship up with router three and locally

92
04:34.140 --> 04:34.900
with router

93
04:34.900 --> 04:37.540
two at the customer side.

94
04:37.540 --> 04:42.760
If we do a show IP route, we see that we are in fact learning routes through O

95
04:42.760 --> 04:43.540
SPF as well

96
04:43.540 --> 04:46.100
as our connected interfaces.

97
04:46.100 --> 04:50.610
And if we do a show VRRP, we see that we are in fact the master and our

98
04:50.610 --> 04:51.660
priority is set

99
04:51.660 --> 04:53.060
to 110.

100
04:53.060 --> 04:55.460
So this is all looking fine.

101
04:55.460 --> 04:58.460
Let's go ahead and set up IPS LA.

102
04:58.460 --> 05:02.020
Now in order to do this, we're going to go into configuration mode.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

102
04:58.460 --> 05:02.020
Now in order to do this, we're going to go into configuration mode.

103
05:02.020 --> 05:08.140
We start off simply by saying IPS LA and you have to give it an entry number.

104
05:08.140 --> 05:12.020
So we'll just start with IPS LA one.

105
05:12.020 --> 05:17.060
This will drop us into configuration mode for IPS LA one.

106
05:17.060 --> 05:20.900
And here we can start configuring what type of probe it is that we want to

107
05:20.900 --> 05:21.740
configure to

108
05:21.740 --> 05:24.160
the other side.

109
05:24.160 --> 05:28.790
As you can see, there are many options here and this is just meant to be an

110
05:28.790 --> 05:29.700
introduction

111
05:29.700 --> 05:31.540
to IPS LA.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

111
05:29.700 --> 05:31.540
to IPS LA.

112
05:31.540 --> 05:35.020
We do not have the time right now to go into all of this.

113
05:35.020 --> 05:39.860
But as you can see, IPS LA is actually a rather large topic and it's a good

114
05:39.860 --> 05:40.500
topic.

115
05:40.500 --> 05:43.820
So you may want to research this a little bit more in the future.

116
05:43.820 --> 05:47.600
But for now, we're just going to take a look at a couple of the different probe

117
05:47.600 --> 05:48.140
types.

118
05:48.140 --> 05:51.420
As you see here though, there are quite a few.

119
05:51.420 --> 05:56.500
What we're going to do is we're just going to start with an ICMP echo, which

120
05:56.500 --> 05:57.100
arguably

121
05:57.100 --> 06:02.820
is probably one of the more common type of IPS LAs to use.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

121
05:57.100 --> 06:02.820
is probably one of the more common type of IPS LAs to use.

122
06:02.820 --> 06:06.780
The next thing we have to provide is of course what device we want to ping.

123
06:06.780 --> 06:08.460
This would be router three.

124
06:08.460 --> 06:14.860
And if you look at our diagram, its address is 172.16.10.3.

125
06:14.860 --> 06:18.720
Then optionally, you don't necessarily have to do this part, but we'll go ahead

126
06:18.720 --> 06:19.460
and specify

127
06:19.460 --> 06:26.140
the source IP as well to ensure that it sources it from the correct interface.

128
06:26.140 --> 06:30.380
So this is going to be the 172.16.10.1.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

128
06:26.140 --> 06:30.380
So this is going to be the 172.16.10.1.

129
06:30.380 --> 06:36.600
If we hit enter here, this will drop us into the configuration specifically for

130
06:36.600 --> 06:37.260
an ICMP

131
06:37.260 --> 06:38.260
echo.

132
06:38.260 --> 06:42.510
So if we hit question mark here, we can see various different things that we

133
06:42.510 --> 06:43.220
can set.

134
06:43.220 --> 06:47.750
And again, we can set things like data patterns and history information and so

135
06:47.750 --> 06:48.420
on, how long

136
06:48.420 --> 06:50.780
it actually keeps the information.

137
06:50.780 --> 06:52.500
So these are important settings.

138
06:52.500 --> 06:56.640
We almost understand, but the main things we want to configure for sure are the

139
06:56.640 --> 06:57.460
frequency,

140
06:57.460 --> 07:00.180
the timeout and the threshold.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

140
06:57.460 --> 07:00.180
the timeout and the threshold.

141
07:00.180 --> 07:02.140
So let's go ahead and configure those.

142
07:02.140 --> 07:05.300
First, we'll configure the threshold.

143
07:05.300 --> 07:08.710
Now the interesting thing about the threshold is this is configured in

144
07:08.710 --> 07:09.700
milliseconds.

145
07:09.700 --> 07:11.820
But what are we configuring?

146
07:11.820 --> 07:17.630
When we send a ping to the other side and it comes back, at what value do we

147
07:17.630 --> 07:19.460
want IPSLA

148
07:19.460 --> 07:22.140
to consider that a failure?

149
07:22.140 --> 07:26.700
Right now, these things are taking right around 40 milliseconds.

150
07:26.700 --> 07:32.220
We saw that when we were doing our testing in part one of this skill.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

150
07:26.700 --> 07:32.220
We saw that when we were doing our testing in part one of this skill.

151
07:32.220 --> 07:34.540
And we'll see it again in just a moment.

152
07:34.540 --> 07:40.280
But since we know it's taking about 40 milliseconds, let's set the threshold to

153
07:40.280 --> 07:41.340
100.

154
07:41.340 --> 07:46.220
Anything over 100 will consider that to be a failure.

155
07:46.220 --> 07:50.140
Next thing we want to do is set the timeout.

156
07:50.140 --> 07:55.100
At what point do we actually stop waiting for the ping to come back and just

157
07:55.100 --> 07:55.620
assume that

158
07:55.620 --> 07:57.260
it's never going to?

159
07:57.260 --> 08:00.220
So this is like a typical ping timeout.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

159
07:57.260 --> 08:00.220
So this is like a typical ping timeout.

160
08:00.220 --> 08:03.460
And this is also set in milliseconds.

161
08:03.460 --> 08:05.460
So this value is not as important.

162
08:05.460 --> 08:08.900
And of course, all of these values are going to depend on your environment.

163
08:08.900 --> 08:14.080
But let's just say for now, we'll set this to 200 when it actually starts

164
08:14.080 --> 08:15.060
timing out.

165
08:15.060 --> 08:19.340
Then we choose how often we want to send our test.

166
08:19.340 --> 08:21.420
So this is frequency.

167
08:21.420 --> 08:25.460
And interestingly enough, this one is in seconds.

168
08:25.460 --> 08:31.260
So the lowest we can set this is to say, test the ping every one second.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

168
08:25.460 --> 08:31.260
So the lowest we can set this is to say, test the ping every one second.

169
08:31.260 --> 08:33.460
So let's go ahead and configure it like that.

170
08:33.460 --> 08:37.100
We'll exit out of IPSLA configuration mode.

171
08:37.100 --> 08:42.340
And the next thing we have to do is actually start the IPSLA.

172
08:42.340 --> 08:45.740
The way we do this is we say IPSLA.

173
08:45.740 --> 08:47.580
We say schedule.

174
08:47.580 --> 08:48.740
Then we put in the number.

175
08:48.740 --> 08:51.340
Again, we created number one.

176
08:51.340 --> 08:56.820
We have to give it a lifetime, a start time, an age out.

177
08:56.820 --> 09:00.700
If it's going to be a recurring timer, this is like most other timers.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

177
08:56.820 --> 09:00.700
If it's going to be a recurring timer, this is like most other timers.

178
09:00.700 --> 09:04.100
We can do all sorts of different scheduling choices here.

179
09:04.100 --> 09:11.050
But a very common thing to do is simply to say start time now and then set the

180
09:11.050 --> 09:12.180
life to

181
09:12.180 --> 09:13.740
forever.

182
09:13.740 --> 09:19.700
Basically, start the probe now and run it until I unschedulate.

183
09:19.700 --> 09:21.660
So let's go ahead and do that.

184
09:21.660 --> 09:24.340
We'll exit configuration mode.

185
09:24.340 --> 09:26.620
And this should be running.

186
09:26.620 --> 09:31.820
You can see this by doing a show IPSLA statistics.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

186
09:26.620 --> 09:31.820
You can see this by doing a show IPSLA statistics.

187
09:31.820 --> 09:33.700
And what do we see here?

188
09:33.700 --> 09:37.950
As I indicated while we were setting it up, we see that the latest round trip

189
09:37.950 --> 09:38.580
time was

190
09:38.580 --> 09:40.620
43 milliseconds.

191
09:40.620 --> 09:47.660
We see most importantly that the last operational return code was okay.

192
09:47.660 --> 09:54.370
This probe thinks everything's fine because 43 milliseconds is below the

193
09:54.370 --> 09:55.660
threshold.

194
09:55.660 --> 10:00.710
We also see that from the time I hit this command, we've had 14 successes and
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

194
09:55.660 --> 10:00.710
We also see that from the time I hit this command, we've had 14 successes and

195
10:00.710 --> 10:02.540
zero failures.

196
10:02.540 --> 10:08.400
We can also, of course, verify the configuration of our probe by saying show

197
10:08.400 --> 10:09.780
IPSLA config.

198
10:09.780 --> 10:13.900
This of course will show you all of the things that we set up.

199
10:13.900 --> 10:16.140
We can see our timeout.

200
10:16.140 --> 10:19.180
We can see this doing an ICMP echo.

201
10:19.180 --> 10:23.250
We can see the target address and the source address a little further down

202
10:23.250 --> 10:24.540
under the schedule.

203
10:24.540 --> 10:28.940
We see the frequency and even further down, we see the threshold.

204
10:28.940 --> 10:33.140
So we can see all the things we configured as well, of course, as a few of the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

204
10:28.940 --> 10:33.140
So we can see all the things we configured as well, of course, as a few of the

205
10:33.140 --> 10:34.120
defaults.

206
10:34.120 --> 10:37.300
Most of these, of course, could be changed as well.

207
10:37.300 --> 10:42.740
So now let's see what happens if we change the latency on our WAN controller.

208
10:42.740 --> 10:46.260
So for this, we'll go to the console of the WAN controller.

209
10:46.260 --> 10:49.100
As you can see, this is an ASCII type interface.

210
10:49.100 --> 10:52.220
So what we want to do is go down to port settings.

211
10:52.220 --> 10:56.250
Here by the way, you can see that 20 milliseconds of latency that it's using

212
10:56.250 --> 10:56.980
right now.

213
10:56.980 --> 11:02.900
Remember, that's 20 milliseconds in each direction, hence the 40 milliseconds.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

213
10:56.980 --> 11:02.900
Remember, that's 20 milliseconds in each direction, hence the 40 milliseconds.

214
11:02.900 --> 11:08.460
Plus, again, as we saw, plus or minus 3 milliseconds for, we'll say, normal

215
11:08.460 --> 11:09.460
latency not being

216
11:09.460 --> 11:12.500
introduced by the WAN emulator.

217
11:12.500 --> 11:17.420
Well, let's change this value to, let's say, 60.

218
11:17.420 --> 11:24.700
If we change this to 60, apply the settings and go back over to router one.

219
11:24.700 --> 11:30.160
So notice as soon as we get back over here to router one, we already have BFD
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

219
11:24.700 --> 11:30.160
So notice as soon as we get back over here to router one, we already have BFD

220
11:30.160 --> 11:31.020
yelling that

221
11:31.020 --> 11:35.600
BFD is down because remember that our BFD is looking at 50 milliseconds and we

222
11:35.600 --> 11:36.000
just

223
11:36.000 --> 11:40.020
upped this to where it's going to be 120, right?

224
11:40.020 --> 11:41.620
60 both directions.

225
11:41.620 --> 11:44.220
So already BFD is having a fit.

226
11:44.220 --> 11:46.940
So again, we want to get this out of the way.

227
11:46.940 --> 11:49.420
So we're not looking at it the whole time.

228
11:49.420 --> 11:53.620
But I just wanted to point out before we turn it off that BFD is going to do

229
11:53.620 --> 11:54.820
its job here,

230
11:54.820 --> 11:57.980
but we want to focus more on IPSLA right now.

231
11:57.980 --> 12:03.640
So let's just go into configuration mode in the router OSPF1 and we'll simply
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

231
11:57.980 --> 12:03.640
So let's just go into configuration mode in the router OSPF1 and we'll simply

232
12:03.640 --> 12:04.860
say, no,

233
12:04.860 --> 12:07.820
BFD on all interfaces.

234
12:07.820 --> 12:10.460
For now, we'll exit configuration.

235
12:10.460 --> 12:15.550
So now let's go back to taking a look at what's going on specifically with IPS

236
12:15.550 --> 12:15.900
LA.

237
12:15.900 --> 12:21.780
So if we look at our show IPSLA statistics again, notice what's going on.

238
12:21.780 --> 12:26.540
Our latest round trip time is 123 milliseconds now.

239
12:26.540 --> 12:29.400
As predicted, remember it's 60 each direction.

240
12:29.400 --> 12:33.740
So 120 total being added by our WAN emulator.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

240
12:29.400 --> 12:33.740
So 120 total being added by our WAN emulator.

241
12:33.740 --> 12:38.460
Notice that now the IPSLA, it's not failing.

242
12:38.460 --> 12:44.140
We still have zero failures because it hasn't gotten to the timeout, but it is

243
12:44.140 --> 12:46.180
over the threshold.

244
12:46.180 --> 12:51.940
So the latest operational return code is over threshold.

245
12:51.940 --> 12:55.540
So let's look at one more type of IPSLA.

246
12:55.540 --> 12:59.820
So to start, let's put our WAN emulator back to the defaults.

247
12:59.820 --> 13:05.900
Let's start by sending our WAN emulator back to only 20 milliseconds of delay.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

247
12:59.820 --> 13:05.900
Let's start by sending our WAN emulator back to only 20 milliseconds of delay.

248
13:05.900 --> 13:07.660
We'll go back to router one.

249
13:07.660 --> 13:12.500
We'll look at our IPSLA statistics again and we see that the last was only 43

250
13:12.500 --> 13:13.500
milliseconds

251
13:13.500 --> 13:14.500
again.

252
13:14.500 --> 13:20.700
So we're back to normal, but let's take a look at a different type of IPSLA.

253
13:20.700 --> 13:24.020
So this time, let's want to configuration mode.

254
13:24.020 --> 13:27.060
Let's just do IPSLA to this time.

255
13:27.060 --> 13:32.460
And this time, let's do a UDP jitter measurement.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

255
13:27.060 --> 13:32.460
And this time, let's do a UDP jitter measurement.

256
13:32.460 --> 13:39.060
Once again, it's going to want the destination address 172.16.10.3.

257
13:39.060 --> 13:40.500
It's going to want to port.

258
13:40.500 --> 13:41.500
It doesn't really matter.

259
13:41.500 --> 13:43.700
We'll just say like port 2000.

260
13:43.700 --> 13:47.100
We can optionally again put in a source IP.

261
13:47.100 --> 13:50.900
The main reason we usually put in a source IP address, by the way, is in case

262
13:50.900 --> 13:51.320
the WAN

263
13:51.320 --> 13:53.300
link does go down.

264
13:53.300 --> 13:56.540
Router one could still get to router three.

265
13:56.540 --> 14:00.760
By sending the traffic around here to router two, router two then forwards it
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

265
13:56.540 --> 14:00.760
By sending the traffic around here to router two, router two then forwards it

266
14:00.760 --> 14:01.380
over here

267
14:01.380 --> 14:06.050
to router four, router four then forwards it up here to router three, and

268
14:06.050 --> 14:06.700
router one

269
14:06.700 --> 14:12.140
is still talking to router three and our probe could still stay up.

270
14:12.140 --> 14:18.260
By specifying the source interface, if the interface goes down, then this will

271
14:18.260 --> 14:18.780
still

272
14:18.780 --> 14:20.080
not work.

273
14:20.080 --> 14:24.910
So again, it's generally better to specify the source IP, although of course,

274
14:24.910 --> 14:25.760
not strictly

275
14:25.760 --> 14:26.760
required.

276
14:26.760 --> 14:31.320
So again, that source is going to be 172.16.10.1.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

276
14:26.760 --> 14:31.320
So again, that source is going to be 172.16.10.1.

277
14:31.320 --> 14:32.600
We'll hit enter.

278
14:32.600 --> 14:37.530
And as you can see, it would help if we actually said source IP, since you can

279
14:37.530 --> 14:38.640
also say source

280
14:38.640 --> 14:39.640
port.

281
14:39.640 --> 14:42.280
So we have to make it non ambiguous.

282
14:42.280 --> 14:45.400
So source IP, that's going to be a little bit better there.

283
14:45.400 --> 14:50.160
Once again, we specify the threshold, we'll keep this at 100.

284
14:50.160 --> 14:51.680
We'll set the timeout.

285
14:51.680 --> 14:53.200
This one will set a little bit higher.

286
14:53.200 --> 14:56.040
Let's just go ahead and set the timeout to one second here.

287
14:56.040 --> 14:59.840
That way we can sort of put the jitter as high as we want.

288
14:59.840 --> 15:03.560
And once again, we'll set the frequency to one second.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

288
14:59.840 --> 15:03.560
And once again, we'll set the frequency to one second.

289
15:03.560 --> 15:05.160
Let's schedule it.

290
15:05.160 --> 15:10.640
So IPSLA schedule two, start now, life forever.

291
15:10.640 --> 15:13.720
We'll exit configuration.

292
15:13.720 --> 15:19.000
How if we do a show IPSLA statistics, it's actually going to show them both.

293
15:19.000 --> 15:21.960
So we're still going to see instance one up here running.

294
15:21.960 --> 15:26.410
And we now see instance two instance two has a bit of a longer output here, as

295
15:26.410 --> 15:26.960
you can

296
15:26.960 --> 15:28.240
see.

297
15:28.240 --> 15:31.630
So if we just want to see instance two, you can actually put the instance
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

297
15:28.240 --> 15:31.630
So if we just want to see instance two, you can actually put the instance

298
15:31.630 --> 15:32.240
number after

299
15:32.240 --> 15:33.240
this.

300
15:33.240 --> 15:36.160
And here it'll just show us two.

301
15:36.160 --> 15:40.780
So as we can see, so far, the round trip values have been right around our 40

302
15:40.780 --> 15:41.800
milliseconds.

303
15:41.800 --> 15:44.800
You can see there 42 to 45 roughly.

304
15:44.800 --> 15:49.970
And down here under the latency, we see some source and destination latency

305
15:49.970 --> 15:50.640
here.

306
15:50.640 --> 15:55.160
Our jitter time is way down in the one to two millisecond range.

307
15:55.160 --> 15:59.920
So now let's go back to our WAN emulator, back to our port settings.

308
15:59.920 --> 16:02.760
This time, let's set the jitter.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

308
15:59.920 --> 16:02.760
This time, let's set the jitter.

309
16:02.760 --> 16:04.040
Let's set that to 200.

310
16:04.040 --> 16:08.080
We'll apply that and go back to router one.

311
16:08.080 --> 16:10.760
Now this will take a little bit of time to average out.

312
16:10.760 --> 16:13.280
So we might have to look at this a few times.

313
16:13.280 --> 16:16.440
Let's go ahead and take a look at number two again.

314
16:16.440 --> 16:20.880
We can see at this point, not a lot has changed as far as like averages and

315
16:20.880 --> 16:21.480
such.

316
16:21.480 --> 16:26.680
However, notice that we are starting to see high values here on the round trip

317
16:26.680 --> 16:27.560
time and

318
16:27.560 --> 16:32.550
down here under over threshold, we're starting to see a percentage of packets,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

318
16:27.560 --> 16:32.550
down here under over threshold, we're starting to see a percentage of packets,

319
16:32.550 --> 16:33.800
in this case,

320
16:33.800 --> 16:37.200
50% that are actually over the threshold.

321
16:37.200 --> 16:39.760
But again, that's just for the round trip time.

322
16:39.760 --> 16:40.760
That's not for the jitter.

323
16:40.760 --> 16:43.120
So let's try looking again.

324
16:43.120 --> 16:46.470
So again, we could let this sit for a while and things would start averaging

325
16:46.470 --> 16:47.080
out a little

326
16:47.080 --> 16:48.080
bit more.

327
16:48.080 --> 16:52.950
But notice, just in this example, we have some source to destination jitter of

328
16:52.950 --> 16:54.880
like 68 milliseconds

329
16:54.880 --> 16:55.880
average.

330
16:55.880 --> 17:01.950
Again, keep in mind what the WAN emulator is doing is it's randomly introducing
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

330
16:55.880 --> 17:01.950
Again, keep in mind what the WAN emulator is doing is it's randomly introducing

331
17:01.950 --> 17:02.720
jitter.

332
17:02.720 --> 17:07.480
It's not introducing 200 milliseconds of jitter on every frame.

333
17:07.480 --> 17:10.120
So our averages aren't going to get to 200.

334
17:10.120 --> 17:11.720
Don't expect that.

335
17:11.720 --> 17:15.320
Notice the latency numbers aren't going up.

336
17:15.320 --> 17:22.200
The jitter times are going up and therefore the overall total round trip times.

337
17:22.200 --> 17:28.380
So as you can see, IPSLA is a very powerful tool for monitoring the quality of

338
17:28.380 --> 17:29.000
our WAN

339
17:29.000 --> 17:30.480
links.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

339
17:29.000 --> 17:30.480
links.

340
17:30.480 --> 17:38.200
So in this video, we saw how to configure IPSLA probes for both ping and UDP j

341
17:38.200 --> 17:39.320
itter to a

342
17:39.320 --> 17:42.000
device on the other side of our WAN.

343
17:42.000 --> 17:46.700
Now this in and of itself doesn't do us a lot of good except for collecting

344
17:46.700 --> 17:47.560
statistics

345
17:47.560 --> 17:52.400
and maybe enforcing an SLA with our service provider.

346
17:52.400 --> 17:57.320
But what we want to do is take a look at actually using this to enforce some

347
17:57.320 --> 17:57.880
form of

348
17:57.880 --> 18:02.240
a policy such as failing over VRRP.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

348
17:57.880 --> 18:02.240
a policy such as failing over VRRP.

349
18:02.240 --> 18:04.680
And there's actually a few ways we can do that.

350
18:04.680 --> 18:06.960
So let's take a look at that in the next video.

351
18:06.960 --> 18:15.040
[BLANK_AUDIO]