WEBVTT

1
00:00.000 --> 00:05.120
Well, this challenge is designed to help us bring together everything we've

2
00:05.120 --> 00:05.560
been talking

3
00:05.560 --> 00:07.400
about, FHRP's.

4
00:07.400 --> 00:10.800
Everything from describing the different properties of the HSRP's when one

5
00:10.800 --> 00:11.720
should be used over

6
00:11.720 --> 00:16.000
the other, when one can be used, when one cannot be used, and then we want to

7
00:16.000 --> 00:16.760
wrap up with

8
00:16.760 --> 00:19.080
FHRP object tracking as well.

9
00:19.080 --> 00:22.210
So if you haven't taken a moment to do this challenge, absolutely hit the pause

10
00:22.210 --> 00:22.640
button

11
00:22.640 --> 00:26.480
and go through this, it will help to solidify all of our understanding of what

12
00:26.480 --> 00:26.880
we've been

13
00:26.880 --> 00:31.860
talking about. And if you're ready to go and you've gone through this, then
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

13
00:26.880 --> 00:31.860
talking about. And if you're ready to go and you've gone through this, then

14
00:31.860 --> 00:32.320
well, let's

15
00:32.320 --> 00:34.560
go start to go through this together.

16
00:34.560 --> 00:39.320
So we're going to use this same topology for all of the individual challenges

17
00:39.320 --> 00:40.240
or the individual

18
00:40.240 --> 00:45.880
scenarios where we have router one and router two servicing a subnet, a VLAN, a

19
00:45.880 --> 00:46.760
broadcast

20
00:46.760 --> 00:50.630
domain, network segment, whatever we want to call it here, go in network

21
00:50.630 --> 00:51.400
segment with

22
00:51.400 --> 00:55.930
clients on it. And then they have upstream layer three connectivity as well,

23
00:55.930 --> 00:56.360
which will

24
00:56.360 --> 00:59.360
tie into the object tracking conversation.

25
00:59.360 --> 01:05.480
So scenario one, our two routers are Cisco gateways.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

25
00:59.360 --> 01:05.480
So scenario one, our two routers are Cisco gateways.

26
01:05.480 --> 01:11.600
We have VLANs in use ranging from 100 to 1500 and we want to match the group ID

27
01:11.600 --> 01:12.600
to the VLAN

28
01:12.600 --> 01:19.450
ID. So we've got a lot of reasons for why we might use one FHRP versus another

29
01:19.450 --> 01:20.080
FHRP.

30
01:20.080 --> 01:24.500
For example, the fact that we have Cisco gateways means that we can use HSRP

31
01:24.500 --> 01:25.680
and GLBP,

32
01:25.680 --> 01:30.000
but we can also use the industry standard VRRP as well. Cisco supports all of
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

33
01:30.000 --> 01:30.960
them. So we've

34
01:30.960 --> 01:35.170
got all of them available, but it's going to be this requirement right here,

35
01:35.170 --> 01:35.800
which helps

36
01:35.800 --> 01:41.420
us to lock in the FHRP we're going to use. Because if we think about the

37
01:41.420 --> 01:43.560
different FHRP's

38
01:43.560 --> 01:52.200
we've talked about, HSRP version one and VRRP, these are going to support 256

39
01:52.200 --> 01:53.320
groups and

40
01:53.320 --> 02:01.920
specifically group IDs ranging from 0 to 255. We get 8 bits. And that comes
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

40
01:53.320 --> 02:01.920
specifically group IDs ranging from 0 to 255. We get 8 bits. And that comes

41
02:01.920 --> 02:02.440
back to the

42
02:02.440 --> 02:07.280
virtual MAC address that's used because depending on which FHRP we're using, we

43
02:07.280 --> 02:07.440
're going

44
02:07.440 --> 02:11.250
to have a bunch of hex characters and then it's going to end with two hex

45
02:11.250 --> 02:12.200
characters that

46
02:12.200 --> 02:20.410
are defined by the group ID. So if we have a group ID of 15, well 15 is 0F in

47
02:20.410 --> 02:21.840
hexadecimal.

48
02:21.840 --> 02:27.190
And so the last two hex characters would be 0F in this case. So the fact that

49
02:27.190 --> 02:27.800
we only have

50
02:27.800 --> 02:35.200
two hex characters means that we have 256 group IDs available. Meanwhile GLBP
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

50
02:27.800 --> 02:35.200
two hex characters means that we have 256 group IDs available. Meanwhile GLBP

51
02:35.200 --> 02:35.720
is a little

52
02:35.720 --> 02:43.820
bit interesting because we actually have 10 bits, which is hard to represent

53
02:43.820 --> 02:44.840
with just

54
02:44.840 --> 02:50.990
X's and Y's as we demonstrated earlier in the videos. But 10 bits gives us a

55
02:50.990 --> 02:53.480
thousand 24 group IDs

56
02:53.480 --> 03:01.530
ranging from 0 to 1023. Now we want to be able to match up to 1500. And so none
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

56
02:53.480 --> 03:01.530
ranging from 0 to 1023. Now we want to be able to match up to 1500. And so none

57
03:01.530 --> 03:02.920
of these

58
03:02.920 --> 03:08.080
FHRP's are going to actually be what's going to be are going to be eligible in

59
03:08.080 --> 03:09.200
this scenario.

60
03:09.200 --> 03:14.670
Instead we're going to need to look at HSRP version 2, which actually gives us

61
03:14.670 --> 03:17.480
a full 12 bits.

62
03:17.480 --> 03:25.890
And that gives us 4,096 group IDs ranging from 0 to 4,095. So what we get here

63
03:25.890 --> 03:26.600
is a virtual

64
03:26.600 --> 03:32.610
MAC address that ends with three full hex characters 12 full bits. And that
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

64
03:26.600 --> 03:32.610
MAC address that ends with three full hex characters 12 full bits. And that

65
03:32.610 --> 03:33.480
allows us to match

66
03:33.480 --> 03:41.190
even VLAN 1500 with a group ID of 1500. So the answer to scenario 1 is going to

67
03:41.190 --> 03:42.320
be HSRP

68
03:42.320 --> 03:46.120
version 2. If you got that right and you tracked with all of this, then we are

69
03:46.120 --> 03:46.680
good to go

70
03:46.680 --> 03:49.360
and we can move on.

71
03:49.360 --> 03:54.570
Scenario 2. Router 1 and router 2 are non-sysco gateways. So that's a very

72
03:54.570 --> 03:56.000
important aspect that

73
03:56.000 --> 04:01.460
we need to be considering. Millicent timers are desired. And we'd also like to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

73
03:56.000 --> 04:01.460
we need to be considering. Millicent timers are desired. And we'd also like to

74
04:01.460 --> 04:01.920
match the

75
04:01.920 --> 04:07.040
FHRP group ID to the VLAN ID. Now to me, this is the most interesting scenario

76
04:07.040 --> 04:08.440
because we have

77
04:08.440 --> 04:12.130
router 1 and router 2 are non-sysco gateways. And we're immediately going to

78
04:12.130 --> 04:13.320
look at that and say,

79
04:13.320 --> 04:19.330
"Ah, okay, I want VRRP." And that would be correct. We do need a version of VR

80
04:19.330 --> 04:20.480
RP here. And

81
04:20.480 --> 04:26.700
the reason for that is non-sysco gateways aren't eligible to run Cisco

82
04:26.700 --> 04:28.880
protocols and HSRP and

83
04:28.880 --> 04:35.320
GLBP both of these are Cisco. We're only going to be able to run these on Cisco
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

83
04:28.880 --> 04:35.320
GLBP both of these are Cisco. We're only going to be able to run these on Cisco

84
04:35.320 --> 04:36.040
devices. So

85
04:36.040 --> 04:40.990
as soon as we see non-sysco, these are not eligible. But we do still have two

86
04:40.990 --> 04:41.520
versions of

87
04:41.520 --> 04:46.150
VRRP. We've got version 2 and version 3, which leads us to the next bullet

88
04:46.150 --> 04:46.920
point here,

89
04:46.920 --> 04:52.330
which is that millisecond timers are desired. Well, VRRP version 2, along with

90
04:52.330 --> 04:53.120
HSRP version

91
04:53.120 --> 04:58.980
1, this is only going to allow us to perform second timers. And the default is

92
04:58.980 --> 04:59.880
going to be a

93
04:59.880 --> 05:03.710
hollow timer of 1 second, a whole timer of 3 seconds. But because I can't do
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

93
04:59.880 --> 05:03.710
hollow timer of 1 second, a whole timer of 3 seconds. But because I can't do

94
05:03.710 --> 05:04.440
millisecond

95
05:04.440 --> 05:08.440
timers, that's as low as it gets from a hello perspective. So if I want to go

96
05:08.440 --> 05:09.720
into the millisecond

97
05:09.720 --> 05:16.570
range, I'm going to need VRRP version 3. The VRRP version 3 is going to give me

98
05:16.570 --> 05:17.360
the ability to

99
05:17.360 --> 05:22.420
have millisecond timers. And so far, we're good to go. VRRP can satisfy both of

100
05:22.420 --> 05:23.520
these requirements.

101
05:23.520 --> 05:27.810
But here's where it gets a little bit interesting. We also want to match the

102
05:27.810 --> 05:29.440
group ID to the VLAN ID.

103
05:29.440 --> 05:36.810
And we just said VRRP version 2 or version 3, both of these only support 256
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

103
05:29.440 --> 05:36.810
And we just said VRRP version 2 or version 3, both of these only support 256

104
05:36.810 --> 05:38.000
groups ranging

105
05:38.000 --> 05:47.140
from 0 to 255. So if we have the same VLANs in place 100 through 1500, then we

106
05:47.140 --> 05:47.960
're going to have a

107
05:47.960 --> 05:53.050
problem here. Now, maybe we don't have VLANs in that range. We actually don't

108
05:53.050 --> 05:54.600
even specify that

109
05:54.600 --> 05:59.410
here within scenario 2. So if the assumption is, all right, as long as we've

110
05:59.410 --> 06:03.840
got VLANs between 0 and 255, 0, I guess,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

110
05:59.410 --> 06:03.840
got VLANs between 0 and 255, 0, I guess,

111
06:03.840 --> 06:09.420
but VLAN 1 to VLAN 255, then we'll be good. Then, hey, all right, VRRP version

112
06:09.420 --> 06:11.760
3 works for us. Otherwise,

113
06:11.760 --> 06:17.960
this is going to be a condition that cannot be met. This is what the scenario

114
06:17.960 --> 06:19.440
or maybe the challenge

115
06:19.440 --> 06:23.920
description was talking about when it said, look for a design, you know, design

116
06:23.920 --> 06:25.120
requirements that maybe

117
06:25.120 --> 06:29.870
can't be met. These right here are conflicting requirements. Generally speaking

118
06:29.870 --> 06:31.920
, we cannot guarantee
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

118
06:29.870 --> 06:31.920
, we cannot guarantee

119
06:31.920 --> 06:37.740
that we can match the FHRP group ID to the VLAN ID if we're using VRRP or GLBP

120
06:37.740 --> 06:39.360
for that matter. It's

121
06:39.360 --> 06:43.060
going to have to be HSRP version 2 at that point, but again, that's why it

122
06:43.060 --> 06:44.240
conflicts with the first

123
06:44.240 --> 06:49.230
bullet point because HSRP version 2 requires non-sysco gateways. So a little

124
06:49.230 --> 06:51.280
bit interesting there, and

125
06:51.280 --> 06:54.710
you might have taken it a different direction and said, well, okay, the

126
06:54.710 --> 06:56.880
conflicting requirement is

127
06:56.880 --> 07:01.520
this one, and we're just going to deploy HSRP version 2 again, but that one
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

127
06:56.880 --> 07:01.520
this one, and we're just going to deploy HSRP version 2 again, but that one

128
07:01.520 --> 07:02.560
would require us

129
07:02.560 --> 07:06.770
purchasing new hardware and management would probably disapprove of that. So

130
07:06.770 --> 07:07.840
scenario 3,

131
07:07.840 --> 07:11.290
router 1 and router 2 are back to being Cisco gateways. All right, the Cisco

132
07:11.290 --> 07:12.560
sales team is doing their job.

133
07:12.560 --> 07:19.730
The desires for both gateways to be forwarding. So this one is probably a

134
07:19.730 --> 07:21.760
little bit straightforward

135
07:21.760 --> 07:30.090
because the whole purpose of GLBP, the gateway load balancing protocol, is to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

135
07:21.760 --> 07:30.090
because the whole purpose of GLBP, the gateway load balancing protocol, is to

136
07:30.090 --> 07:31.040
load balance between

137
07:31.040 --> 07:36.700
two gateways. So if we're running HSRP or VRRP, all of our client traffic down

138
07:36.700 --> 07:38.720
here is going to have

139
07:38.720 --> 07:43.370
to go through the active gateway, which means that this guy over here is

140
07:43.370 --> 07:47.120
sitting there bored. So GLBP

141
07:47.120 --> 07:52.880
is the protocol we can deploy to allow for the load balancing of traffic out

142
07:52.880 --> 07:54.080
both of these gateways.

143
07:54.080 --> 07:57.720
And the way we do that is by having two different v-max. So we have v-max 1 on

144
07:57.720 --> 07:59.920
the left, v-max 2 on the

145
07:59.920 --> 08:05.760
right. And so if we have a client show up, it's going to think that its default
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

145
07:59.920 --> 08:05.760
right. And so if we have a client show up, it's going to think that its default

146
08:05.760 --> 08:07.760
gateway is pointing to

147
08:07.760 --> 08:15.340
v-max 1 equals my gateway. Whereas the next host to show up is going to think

148
08:15.340 --> 08:16.800
that v-max 2

149
08:16.800 --> 08:21.800
represents its gateway. And this would be the load balancing mechanism that we

150
08:21.800 --> 08:22.880
use. So remember,

151
08:22.880 --> 08:26.070
one of these devices is going to be the AVG and it's going to handle the

152
08:26.070 --> 08:28.080
distribution of the v-max.

153
08:28.080 --> 08:33.040
So in some fashion, we're going to have roughly half the clients using v-max 1,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

153
08:28.080 --> 08:33.040
So in some fashion, we're going to have roughly half the clients using v-max 1,

154
08:33.040 --> 08:33.760
half the clients

155
08:33.760 --> 08:37.490
using v-max 2, and we have several load balancing algorithms to help us out

156
08:37.490 --> 08:39.600
there. So the answer,

157
08:39.600 --> 08:43.250
for scenario 3 is certainly GLBP. Let's just make sure we remember the

158
08:43.250 --> 08:45.440
mechanisms for how GLBP works.

159
08:46.400 --> 08:52.160
So let's scroll down a little bit here. We have a final scenario, which is

160
08:52.160 --> 08:54.320
scenario 4.

161
08:54.320 --> 09:00.960
So lastly, this organization recently experienced an outage on R1's uplink. So
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

161
08:54.320 --> 09:00.960
So lastly, this organization recently experienced an outage on R1's uplink. So

162
09:00.960 --> 09:02.400
remember, both of these

163
09:02.400 --> 09:09.680
routers have an activity up to the layer 3 domain. And apparently we lost

164
09:09.680 --> 09:10.240
communication.

165
09:10.880 --> 09:16.600
Let's change the color there. We lost access on this uplink. And even though we

166
09:16.600 --> 09:18.080
've got redundancy for

167
09:18.080 --> 09:25.760
our clients on these two routers, we lost connection. That's a terrible two.

168
09:25.760 --> 09:26.480
That looks like a 3.

169
09:26.480 --> 09:32.320
There we go. So we know that R1 is the active for HSRP.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

169
09:26.480 --> 09:32.320
There we go. So we know that R1 is the active for HSRP.

170
09:34.880 --> 09:39.000
And the question is, how can we prevent this in the future? Because our clients

171
09:39.000 --> 09:41.360
should be able to use

172
09:41.360 --> 09:46.110
the redundant path out router 2. But instead, clearly they were still going to

173
09:46.110 --> 09:46.880
router 1.

174
09:46.880 --> 09:50.330
And because router 1 didn't have a path to the rest of the network, the traffic

175
09:50.330 --> 09:51.280
was just getting dropped.

176
09:51.280 --> 09:56.950
So what we want to do is we want to leverage SHRP tracking, which is the answer

177
09:56.950 --> 09:58.400
to the first question

178
09:58.400 --> 10:03.840
here, which is what mechanism can be used. This would be object tracking.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

178
09:58.400 --> 10:03.840
here, which is what mechanism can be used. This would be object tracking.

179
10:03.840 --> 10:10.840
Object tracking is going to allow us to track the status of an object. In our

180
10:10.840 --> 10:12.240
case, we've got a lot

181
10:12.240 --> 10:17.340
of options here. I could track the actual link. I could track a IP address up

182
10:17.340 --> 10:18.560
here. I could track

183
10:18.560 --> 10:22.610
a route in the routing table, or I could leverage Cisco's IPSLA, which as we

184
10:22.610 --> 10:24.320
mentioned is a whole other

185
10:24.320 --> 10:29.440
suite of capabilities. So what's going to be tracked in this scenario,

186
10:29.440 --> 10:31.440
specifically saying that
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

186
10:29.440 --> 10:31.440
specifically saying that

187
10:31.440 --> 10:36.440
this uplink went down, we'd probably track the link itself, which as we recall

188
10:36.440 --> 10:38.000
is the option called

189
10:38.000 --> 10:43.680
line protocol. Basically saying, is this line, is this link online? So that

190
10:43.680 --> 10:45.200
would be what we might

191
10:45.200 --> 10:48.680
want to track. If you said that we would track the routing table to make sure

192
10:48.680 --> 10:49.520
we have a route

193
10:49.520 --> 10:54.480
upstream, or if you said that we would track an IP address or leverage IPL SLA,

194
10:54.480 --> 10:55.200
there really is no

195
10:55.200 --> 10:59.170
wrong answer to the second bullet point, as long as you were intentional with

196
10:59.170 --> 11:00.240
what you were picking.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

196
10:59.170 --> 11:00.240
what you were picking.

197
11:00.240 --> 11:06.240
Now lastly, how are we going to force the failover? That is the goal after all.

198
11:06.240 --> 11:07.280
We want to force

199
11:07.280 --> 11:13.120
R1 to failover to R2, so that R2 can become the active, even though router 1 is

200
11:13.120 --> 11:14.320
still online.

201
11:15.040 --> 11:18.450
So what are we going to do? We're going to use dynamic priorities and that

202
11:18.450 --> 11:20.880
decrement concept. So maybe

203
11:20.880 --> 11:28.740
what we'll do is we'll say that router 1 has a priority of 150 and router 2

204
11:28.740 --> 11:30.320
will have a priority
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

204
11:28.740 --> 11:30.320
will have a priority

205
11:30.320 --> 11:37.770
of 100. And we just need to set decrement values so that router 1 gets, you

206
11:37.770 --> 11:39.600
know, lower than router 2.

207
11:39.600 --> 11:44.140
So I could say I'm going to decrement this tracking, whatever it is we're

208
11:44.140 --> 11:45.920
tracking. So we said we're

209
11:45.920 --> 11:51.450
tracking the line protocol here, but I'm going to decrement by 100 if that link

210
11:51.450 --> 11:52.160
goes down.

211
11:52.160 --> 11:59.420
And so when the link goes down, my priority will drop to 50 and that'll be less

212
11:59.420 --> 12:00.400
than 100 on the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

212
11:59.420 --> 12:00.400
than 100 on the

213
12:00.400 --> 12:04.510
other side. At that point it will prompt a failover question mark question mark

214
12:04.510 --> 12:07.200
. We have to think

215
12:07.200 --> 12:11.010
through there is one other mechanism that's very important to this process

216
12:11.010 --> 12:12.480
because by default,

217
12:12.480 --> 12:15.750
especially if we're running HSRP, which is what we're running, we do not

218
12:15.750 --> 12:17.760
automatically failover,

219
12:17.760 --> 12:23.150
even if our priority is lower than the other. So what do we need to do? We need

220
12:23.150 --> 12:24.880
to deploy preemption.

221
12:24.880 --> 12:31.280
So we would have to enable preemption at least on the backup node, but probably
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

221
12:24.880 --> 12:31.280
So we would have to enable preemption at least on the backup node, but probably

222
12:31.280 --> 12:32.400
on the primary note

223
12:32.400 --> 12:37.030
as well in case it comes back online. That's typically what we do in real world

224
12:37.030 --> 12:38.800
designs, but this is

225
12:38.800 --> 12:45.160
the required part because once our primary goes down to 50, our active node, we

226
12:45.160 --> 12:46.800
want the standby node

227
12:46.800 --> 12:51.420
to be able to preempt to say I have a higher priority than you and that allows

228
12:51.420 --> 12:52.480
me to become the

229
12:52.480 --> 12:58.210
active. Now my clients can take the redundant path through router 2 and life

230
12:58.210 --> 13:01.040
will be good. So that is
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

230
12:58.210 --> 13:01.040
will be good. So that is

231
13:01.040 --> 13:07.440
a pretty fun scenario. The object tracking is something that is a requirement

232
13:07.440 --> 13:09.120
in our network designs.

233
13:09.120 --> 13:12.140
It's something that can very easily get overlooked in a lot of network

234
13:12.140 --> 13:13.280
organizations. It might be time

235
13:13.280 --> 13:18.760
to go out and make sure your own network is taking advantage of FHFHRP object

236
13:18.760 --> 13:20.160
tracking because

237
13:20.160 --> 13:24.660
chances are if we don't have object tracking in place, there could well be a

238
13:24.660 --> 13:25.840
scenario where we're

239
13:25.840 --> 13:29.840
either black holding traffic or if we do have a routing relationship between

240
13:29.840 --> 13:30.720
those two routers,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

240
13:29.840 --> 13:30.720
those two routers,

241
13:30.720 --> 13:34.870
it will at least be inefficient and result in asymmetric routing as we

242
13:34.870 --> 13:36.240
described in the previous

243
13:36.240 --> 13:43.910
skill or a previous video earlier on in the skill. So that is a wrap up for FH

244
13:43.910 --> 13:45.440
RP and object tracking

245
13:45.440 --> 13:48.420
conversation. I hope this has been informative for you and I'd like to thank

246
13:48.420 --> 13:49.200
you for viewing.