WEBVTT

1
00:00.000 --> 00:02.040
Alright, here we go again.

2
00:02.040 --> 00:05.640
We're going to jump back into a quiz and review some of the topics, especially

3
00:05.640 --> 00:07.320
around FHRP's.

4
00:07.320 --> 00:10.080
Once again, hit the pause button as needed in order to make sure you can answer

5
00:10.080 --> 00:10.400
these

6
00:10.400 --> 00:11.960
questions yourselves.

7
00:11.960 --> 00:15.240
So we start by looking at the multi-cast addresses.

8
00:15.240 --> 00:21.600
Identify the FHRP that uses each of the following multi-cast addresses.

9
00:21.600 --> 00:26.780
So we may recall that HSRP version 1 came out and Cisco didn't have a dedicated

10
00:26.780 --> 00:27.320
multi-cast

11
00:27.320 --> 00:32.860
address for it. So it uses this .2 which even today is used to multi-cast to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

11
00:27.320 --> 00:32.860
address for it. So it uses this .2 which even today is used to multi-cast to

12
00:32.860 --> 00:34.040
all routers.

13
00:34.040 --> 00:38.800
So any layer 3 device will receive this. Not really ideal.

14
00:38.800 --> 00:44.840
When VRRP came out, they had 224.0.0.18 reserved for them.

15
00:44.840 --> 00:50.440
And so again, VRRP is the industry standard FHRP that can be used.

16
00:50.440 --> 00:54.430
Version 2 and Version 3 both use the same address, keeping in mind that Version

17
00:54.430 --> 00:55.760
3 has an IPv6

18
00:55.760 --> 01:01.000
address equivalent, which turns this into hex of 12. So don't forget that.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

18
00:55.760 --> 01:01.000
address equivalent, which turns this into hex of 12. So don't forget that.

19
01:01.000 --> 01:06.900
Now lastly, this .102 was created, or maybe I should say reserved by Cisco, for

20
01:06.900 --> 01:07.880
HSRP version

21
01:07.880 --> 01:14.310
2 and also GLBP. So they double dipped here. They said, you know, very rarely

22
01:14.310 --> 01:14.800
will we see

23
01:14.800 --> 01:18.580
both of these in the same broadcast domain. And so let's just use the same

24
01:18.580 --> 01:19.160
multi-cast

25
01:19.160 --> 01:24.000
address. Again, we can use both of these in the same broadcast domain.

26
01:24.000 --> 01:29.040
It's just the GLBP nodes will be receiving HSRP version 2 messages and vice

27
01:29.040 --> 01:29.800
versa. And

28
01:29.800 --> 01:34.000
they'll drop it. It's just not as efficient. So no real need for each one to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

28
01:29.800 --> 01:34.000
they'll drop it. It's just not as efficient. So no real need for each one to

29
01:34.000 --> 01:34.760
get its own

30
01:34.760 --> 01:36.560
multi-cast address.

31
01:36.560 --> 01:42.490
All right, you knew it was coming. Here we go. Can we match these virtual MAC

32
01:42.490 --> 01:43.120
addresses

33
01:43.120 --> 01:47.280
up to each of the FHRP's? And that's what this question's asking. So hit the

34
01:47.280 --> 01:47.800
pause button

35
01:47.800 --> 01:51.280
and make sure you can go through this exercise.

36
01:51.280 --> 01:56.300
So to start with, when we see this, all zeros with the 5E in there, that should

37
01:56.300 --> 01:57.080
tell us that

38
01:57.080 --> 02:05.980
we're running VRRP. VRRP has the 0, 0, 0, 0, 5E, 0, 0, 1. And here, this would
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

38
01:57.080 --> 02:05.980
we're running VRRP. VRRP has the 0, 0, 0, 0, 5E, 0, 0, 1. And here, this would

39
02:05.980 --> 02:06.720
be the group

40
02:06.720 --> 02:13.370
ID. We only get the two hex characters, which means 8 bits, which means 2 to

41
02:13.370 --> 02:14.320
the 8th power

42
02:14.320 --> 02:21.240
of 256 groups. Next, we see 0C. So anytime we see 0C, maybe that C can remind

43
02:21.240 --> 02:21.240
us of

44
02:21.240 --> 02:26.110
just that it's for Cisco. It's one of Cisco's HSRP VMAX. We just have to keep

45
02:26.110 --> 02:26.520
track of the

46
02:26.520 --> 02:32.460
difference. It might also help that this 07 is much lower than 9F. And so 07,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

46
02:26.520 --> 02:32.460
difference. It might also help that this 07 is much lower than 9F. And so 07,

47
02:32.460 --> 02:32.920
we could

48
02:32.920 --> 02:38.650
think along these lines that it came first. And this is for HSRP version 1 with

49
02:38.650 --> 02:39.200
the last

50
02:39.200 --> 02:45.660
two hex characters giving us those 256 groups. And then this last one down here

51
02:45.660 --> 02:47.280
, 9FF versus

52
02:47.280 --> 02:53.980
07 AC by the way, but 9FF, this is HSRP version 2. And we actually have all

53
02:53.980 --> 02:55.560
three of these hex

54
02:55.560 --> 03:01.780
characters, which means 12 bits and 10 to the 12th power gives us the 4,096
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

54
02:55.560 --> 03:01.780
characters, which means 12 bits and 10 to the 12th power gives us the 4,096

55
03:01.780 --> 03:02.600
groups. Pretty

56
03:02.600 --> 03:07.360
cool with HSRP version 2 giving us that. Now, lastly, by process of elimination

57
03:07.360 --> 03:07.760
, we have

58
03:07.760 --> 03:13.460
GLBP in here. We can recognize that GLBP is sort of an outlier. It's a weird

59
03:13.460 --> 03:14.600
protocol.

60
03:14.600 --> 03:20.120
And weirdly, it's the only one that has a non-zero digit here as the, or in the

61
03:20.120 --> 03:20.960
first

62
03:20.960 --> 03:26.440
section of our MAC address. Also, keep in mind that we have 10 bits in here.

63
03:26.440 --> 03:27.080
Yes, there's

64
03:27.080 --> 03:32.120
12 bits total, but we only get 10 of those for groups. So we get 1,024 groups.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

64
03:27.080 --> 03:32.120
12 bits total, but we only get 10 of those for groups. So we get 1,024 groups.

65
03:32.120 --> 03:32.240
And then

66
03:32.240 --> 03:39.040
this last pairing would define an AVF identifier.

67
03:39.040 --> 03:45.760
And 3, what mechanism is used following an FHRP failover to update the layer 2

68
03:45.760 --> 03:46.880
network?

69
03:46.880 --> 03:52.830
So the answer to this would be the garb as I prioritize drawing out the diagram

70
03:52.830 --> 03:53.600
here.

71
03:53.600 --> 03:58.010
But remember, if I've got a network switch here, a network switch over here,

72
03:58.010 --> 03:59.040
network switches

73
03:59.040 --> 04:04.400
like this, whatever the topology is, if the active is over here, this is where
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

73
03:59.040 --> 04:04.400
like this, whatever the topology is, if the active is over here, this is where

74
04:04.400 --> 04:05.160
the V MAC

75
04:05.160 --> 04:11.240
lives. And this switch down here thinks the V MAC lives out this way. And so if

76
04:11.240 --> 04:12.000
this device

77
04:12.000 --> 04:17.320
goes down, by default, I still think the V MAC lives out this link. And so if I

78
04:17.320 --> 04:17.680
receive

79
04:17.680 --> 04:23.090
a packet destined for the gateway, that layer 2 frame will get forwarded to

80
04:23.090 --> 04:24.200
this switch,

81
04:24.200 --> 04:28.470
this switch recognizes, well, I used to think the V MAC lived out here. That

82
04:28.470 --> 04:28.840
link is now

83
04:28.840 --> 04:32.960
down. And so I just don't have an entry for it. So I'm going to flood it out
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

83
04:28.840 --> 04:32.960
down. And so I just don't have an entry for it. So I'm going to flood it out

84
04:32.960 --> 04:33.560
all ports.

85
04:33.560 --> 04:36.470
Well, that's great. And I'll accept I can't flood it out the port I received it

86
04:36.470 --> 04:37.000
on. So it's

87
04:37.000 --> 04:40.960
going to flood it out a bunch of ports. And it's just going to get black hold.

88
04:40.960 --> 04:41.320
And so we

89
04:41.320 --> 04:46.610
want to update the layer to network. So as soon as the secondary realizes, hey,

90
04:46.610 --> 04:47.160
I need

91
04:47.160 --> 04:52.810
to do a failover. I'm going to activate that virtual IP address. And I'm going

92
04:52.810 --> 04:53.160
to send

93
04:53.160 --> 04:59.550
out a gratuitous ARP or a garb that is the ARP nobody asked for. And yet I'm

94
04:59.550 --> 04:59.760
flooding

95
04:59.760 --> 05:04.350
it out into the network. So I can see, oh, the V MAC lives out this way now.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

95
04:59.760 --> 05:04.350
it out into the network. So I can see, oh, the V MAC lives out this way now.

96
05:04.350 --> 05:05.000
And the V MAC

97
05:05.000 --> 05:10.330
lives out this way now. And everybody now knows where that V MAC lives. And it

98
05:10.330 --> 05:10.880
will prevent

99
05:10.880 --> 05:16.080
the black holding of traffic. Very important. And yet under maybe studied or

100
05:16.080 --> 05:17.840
maybe misunderstood

101
05:17.840 --> 05:22.260
element of FHRPs, absolutely something we want to be certain we understand as

102
05:22.260 --> 05:22.840
far as the

103
05:22.840 --> 05:23.960
process is concerned.

104
05:23.960 --> 05:29.130
All right, question four. And there are six questions, by the way. So we're

105
05:29.130 --> 05:29.880
over halfway

106
05:29.880 --> 05:35.240
there. A network engineer configures GLBP among four gateways deploying group
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

106
05:29.880 --> 05:35.240
there. A network engineer configures GLBP among four gateways deploying group

107
05:35.240 --> 05:37.320
84 on VLAN 110.

108
05:37.320 --> 05:43.390
What V MAC is used by an AVF with an ID of 11 Holy smokes. There is a lot of

109
05:43.390 --> 05:44.000
information

110
05:44.000 --> 05:49.100
in here. Remember GLBP defines its virtual MAC address not only on the group ID

111
05:49.100 --> 05:49.680
, but also

112
05:49.680 --> 05:54.860
on the AVF identifier. Those last two hex characters are all about the

113
05:54.860 --> 05:56.920
identifier and for the

114
05:56.920 --> 06:02.120
AVF and the other 10 bits to find the group ID. The VLAN ID has nothing to do
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

114
05:56.920 --> 06:02.120
AVF and the other 10 bits to find the group ID. The VLAN ID has nothing to do

115
06:02.120 --> 06:02.840
with this.

116
06:02.840 --> 06:07.530
So don't let that distract you as we go down this path. We also need to worry

117
06:07.530 --> 06:08.360
about hex.

118
06:08.360 --> 06:12.620
So we need to convert all of these numbers to hex. If we were to convert 84 to

119
06:12.620 --> 06:13.000
hex,

120
06:13.000 --> 06:19.010
for example, 80 is 16 times 5. So I'd be a 5 with a remainder of 4. So that's a

121
06:19.010 --> 06:19.480
hex value

122
06:19.480 --> 06:25.870
of 54 110, even though we're not going to use it. This is where we might see 6E

123
06:25.870 --> 06:27.000
, where

124
06:27.000 --> 06:34.360
we take 16, multiply it by 6, get 96. We have a remainder of 14 and E is hex
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

124
06:27.000 --> 06:34.360
we take 16, multiply it by 6, get 96. We have a remainder of 14 and E is hex

125
06:34.360 --> 06:35.720
for 14. And

126
06:35.720 --> 06:39.280
then lastly, 11, don't have to do a whole lot of math on that one. Just

127
06:39.280 --> 06:40.040
recognize that it

128
06:40.040 --> 06:45.550
goes from 9 to 10 is a to 11 is b. So that b zero b here. But again, we're not

129
06:45.550 --> 06:45.840
going to

130
06:45.840 --> 06:52.770
use 6E. So first of all, we see that the OUI is the same for all of these. That

131
06:52.770 --> 06:54.240
's good.

132
06:54.240 --> 06:59.370
We could possibly see this value change down here because if we get a group ID

133
06:59.370 --> 07:00.200
that's large
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

133
06:59.370 --> 07:00.200
that's large

134
07:00.200 --> 07:04.400
enough and we need those two bits, remember we kind of divide those four bits

135
07:04.400 --> 07:05.080
and half,

136
07:05.080 --> 07:09.160
we get those last two, then we might see that number change to one or two or

137
07:09.160 --> 07:09.920
something

138
07:09.920 --> 07:18.530
like that. But either way, again, our group ID here is 54 and hex and the group

139
07:18.530 --> 07:20.000
ID comes first.

140
07:20.000 --> 07:25.980
So that would be right here. And then the AVF identifier of 11, which is zero b

141
07:25.980 --> 07:26.720
, would

142
07:26.720 --> 07:31.760
go right here. So our answer is going to be b. Don't get distracted by decimal
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

142
07:26.720 --> 07:31.760
go right here. So our answer is going to be b. Don't get distracted by decimal

143
07:31.760 --> 07:32.560
values.

144
07:32.560 --> 07:37.450
Don't get distracted by VLAN identifiers in here. We want to make sure we know

145
07:37.450 --> 07:37.680
how the

146
07:37.680 --> 07:44.170
vmix are structured, not just for GLBP, but also for HSRP, both versions and VR

147
07:44.170 --> 07:46.920
RP as well.

148
07:46.920 --> 07:51.680
Question five, which FHRP configuration is required in order to use object

149
07:51.680 --> 07:52.720
tracking? So

150
07:52.720 --> 07:57.810
we're going to use a series of configurations with a FHRP. But the answer to

151
07:57.810 --> 07:58.720
this question

152
07:58.720 --> 08:03.170
is going to be preemption because we don't need authentication and we don't
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

152
07:58.720 --> 08:03.170
is going to be preemption because we don't need authentication and we don't

153
08:03.170 --> 08:04.040
need millisecond

154
08:04.040 --> 08:08.790
timers. We do need dynamic priority values. That's how we do it. We use that

155
08:08.790 --> 08:10.120
decrement command.

156
08:10.120 --> 08:16.050
But that doesn't require us to use a priority greater than 100. I could use 50

157
08:16.050 --> 08:17.760
and 90 and we

158
08:17.760 --> 08:21.940
could perform object tracking just fine. So we don't need to use specific

159
08:21.940 --> 08:23.200
priority values.

160
08:23.200 --> 08:26.500
We just need to make sure that relatively I can drop the prior, let's say the

161
08:26.500 --> 08:28.040
active is 90.

162
08:28.040 --> 08:32.310
I need to drop that priority value below the secondary. So I drop it to maybe
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

162
08:28.040 --> 08:32.310
I need to drop that priority value below the secondary. So I drop it to maybe

163
08:32.310 --> 08:33.000
40. I do

164
08:33.000 --> 08:37.860
a decrement of 50 here when an outage occurs that prompts a failover, even

165
08:37.860 --> 08:38.680
though the active

166
08:38.680 --> 08:42.700
node is still alive, there's network degradation that we're trying to take into

167
08:42.700 --> 08:43.880
account. We decrement

168
08:43.880 --> 08:48.510
50. I'm at 40 now. So that's all well and good. But if I'm sitting here as the

169
08:48.510 --> 08:50.520
active at 40

170
08:50.520 --> 08:54.500
and the secondary sitting here at 50 and preemption is not enabled, nothing's

171
08:54.500 --> 08:55.800
going to change.

172
08:55.800 --> 09:01.290
I must have preemption enabled on the secondary so that I can see that I'm now
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

172
08:55.800 --> 09:01.290
I must have preemption enabled on the secondary so that I can see that I'm now

173
09:01.290 --> 09:02.200
better than

174
09:02.200 --> 09:07.920
you. And I take the active role, which again does require preemption. Pre

175
09:07.920 --> 09:08.840
emption is disabled

176
09:08.840 --> 09:13.800
by default with HSRP. So we need to enable it at that point. If we're using VR

177
09:13.800 --> 09:14.960
RP, it is enabled

178
09:14.960 --> 09:17.960
by default. And so we're pretty good there.

179
09:17.960 --> 09:22.900
All right, last question for this quiz, which mechanism is responsible for

180
09:22.900 --> 09:24.040
preventing routing

181
09:24.040 --> 09:30.590
a J-sensee flaps during a chassis supervisor failover? We probably often hear
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

181
09:24.040 --> 09:30.590
a J-sensee flaps during a chassis supervisor failover? We probably often hear

182
09:30.590 --> 09:32.120
SSO and NSF

183
09:32.120 --> 09:36.030
that are usually talked about together almost in one breath as if they do the

184
09:36.030 --> 09:36.760
same thing,

185
09:36.760 --> 09:41.410
but they do different things. Staple switchover is going to make sure that when

186
09:41.410 --> 09:43.560
I have a primary

187
09:43.560 --> 09:48.980
supervisor and a redundant supervisor that whatever's happening here in my

188
09:48.980 --> 09:50.120
tables, especially

189
09:50.120 --> 09:57.390
my routing tables, that this gets actively synchronized, this is staple switch

190
09:57.390 --> 09:58.320
over, actively

191
09:58.320 --> 10:03.560
synchronized to the redundant supervisor, which means also that this redundant
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

191
09:58.320 --> 10:03.560
synchronized to the redundant supervisor, which means also that this redundant

192
10:03.560 --> 10:04.400
supervisor

193
10:04.400 --> 10:09.840
is online and ready to failover. So this is as hot of a standby as we can be.

194
10:09.840 --> 10:10.240
And if this

195
10:10.240 --> 10:14.340
goes down as soon as we detect that supervisor failed for any reason, I can

196
10:14.340 --> 10:15.400
immediately come

197
10:15.400 --> 10:22.040
online and I've got all of the table entries already populated. So that is SSO.

198
10:22.040 --> 10:22.200
But that's

199
10:22.200 --> 10:26.920
not what we're asking about here. We're asking about routing a J-sensee flaps.

200
10:26.920 --> 10:27.040
Because

201
10:27.040 --> 10:34.800
this device here has a routing a J-sensee with another device. And so remember,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

201
10:27.040 --> 10:34.800
this device here has a routing a J-sensee with another device. And so remember,

202
10:34.800 --> 10:35.440
this is going

203
10:35.440 --> 10:41.430
to be down for some amount of time, that is a clock, representing time. And so

204
10:41.430 --> 10:42.800
while this is down,

205
10:42.800 --> 10:48.560
we might have millisecond timers that this device here is expecting to receive

206
10:48.560 --> 10:50.080
hello messages on.

207
10:50.080 --> 10:55.390
Well, I haven't failed over yet because maybe it takes me three seconds to

208
10:55.390 --> 10:56.160
detect that there's

209
10:56.160 --> 11:00.730
an outage or whatever the situation is. And by default, this device is going to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

209
10:56.160 --> 11:00.730
an outage or whatever the situation is. And by default, this device is going to

210
11:00.730 --> 11:01.520
tear down this

211
11:01.520 --> 11:06.580
a J-sensee because it thinks, right, fully so, on some level that its neighbor

212
11:06.580 --> 11:09.200
has died. So we want

213
11:09.200 --> 11:15.010
to keep that a J-sensee online and show some amount of grace to say, "Hey, I

214
11:15.010 --> 11:16.240
know that I'm not

215
11:16.240 --> 11:21.720
sending any hello messages, but I am NSF capable and therefore you need to show

216
11:21.720 --> 11:22.880
me grace while I

217
11:22.880 --> 11:28.620
try to perform a failover." That is the function of NSF nonstop forwarding. The

218
11:28.620 --> 11:31.040
idea here is that I can
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

218
11:28.620 --> 11:31.040
idea here is that I can

219
11:31.040 --> 11:36.290
maintain my adjacencies and I can continue to forward packets by the way, even

220
11:36.290 --> 11:37.280
though the control

221
11:37.280 --> 11:42.290
plane is down, in order to hopefully allow me to continue to switch traffic,

222
11:42.290 --> 11:42.960
which depending on the

223
11:42.960 --> 11:46.690
architecture of the chassis will allow me to keep doing while the supervisors

224
11:46.690 --> 11:47.760
are failing over.