WEBVTT

1
00:00.000 --> 00:04.440
We have a lot of options for first-hop redundancy protocols.

2
00:04.440 --> 00:11.120
We can deploy for example Cisco's hot standby router protocol or HSRP as one of

3
00:11.120 --> 00:12.600
these options.

4
00:12.600 --> 00:17.790
Now Cisco was the first to really create one of these protocols in HSRP and so

5
00:17.790 --> 00:18.360
they were

6
00:18.360 --> 00:27.100
very early on they had HSRP version 1 and later on they released HSRP version 2

7
00:27.100 --> 00:27.280
.

8
00:27.280 --> 00:30.560
These days we should absolutely be running version 2 and we'll talk about the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

8
00:27.280 --> 00:30.560
These days we should absolutely be running version 2 and we'll talk about the

9
00:30.560 --> 00:31.040
differences

10
00:31.040 --> 00:36.730
here but since Cisco actually still supports HSRP version 1 in fact it's the

11
00:36.730 --> 00:38.360
default configuration

12
00:38.360 --> 00:42.320
if you add HSRP onto your device.

13
00:42.320 --> 00:48.080
So we need to be careful as far as explicitly enabling HSRP version 2 in order

14
00:48.080 --> 00:48.720
to add

15
00:48.720 --> 00:52.040
HSRP to our configurations.

16
00:52.040 --> 01:00.850
Now the idea of HSRP is to create groups that are going to operate per subnet
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

16
00:52.040 --> 01:00.850
Now the idea of HSRP is to create groups that are going to operate per subnet

17
01:00.850 --> 01:01.840
and ultimately

18
01:01.840 --> 01:04.720
per VLAN.

19
01:04.720 --> 01:09.550
So I might have for example a pair of multilayer switches, we've got layer 2

20
01:09.550 --> 01:10.520
connectivity

21
01:10.520 --> 01:14.640
between them and then I've got three sets of SVIs.

22
01:14.640 --> 01:19.850
So let's say I've got SVIs for VLANs 10, 20 and 30 on the left and then SVIs

23
01:19.850 --> 01:20.920
for 10,

24
01:20.920 --> 01:23.840
20 and 30 on the right.

25
01:23.840 --> 01:29.360
I'd say left or right on that either way, 10, 20, 30 on the left, 10, 20, 30 on

26
01:29.360 --> 01:30.640
the right.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

26
01:29.360 --> 01:30.640
the right.

27
01:30.640 --> 01:33.320
So what we're going to do is we're going to create groups.

28
01:33.320 --> 01:40.820
So I might create group 10 and group 10 is going to be for our SVIs in VLAN 10

29
01:40.820 --> 01:41.000
and then

30
01:41.000 --> 01:48.810
I can create groups 20 and 30 to do the same thing for the SVIs in VLANs 20 and

31
01:48.810 --> 01:49.760
30.

32
01:49.760 --> 01:56.620
Please make sure that as we send HSRP messaging back and forth that we're not

33
01:56.620 --> 01:58.120
failing over

34
01:58.120 --> 02:03.600
to, I don't know, let's say that the SVI for VLAN 10 goes down on the right.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

34
01:58.120 --> 02:03.600
to, I don't know, let's say that the SVI for VLAN 10 goes down on the right.

35
02:03.600 --> 02:08.880
We wouldn't want to fail over, this is the active note over here.

36
02:08.880 --> 02:13.070
We might want to fail over for VLAN 10 but we don't also want to fail over for

37
02:13.070 --> 02:14.040
VLANs 20

38
02:14.040 --> 02:15.280
and 30.

39
02:15.280 --> 02:16.280
That wouldn't be conducive.

40
02:16.280 --> 02:20.880
We would stay online over here and we want to have as few failovers as possible

41
02:20.880 --> 02:21.120
in order

42
02:21.120 --> 02:25.720
to promote stability in the network.

43
02:25.720 --> 02:31.350
So the groups help us to identify which ones or which gateways are paired up
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

43
02:25.720 --> 02:31.350
So the groups help us to identify which ones or which gateways are paired up

44
02:31.350 --> 02:32.080
with one

45
02:32.080 --> 02:36.840
another so that we can make sure that we're performing our redundancy checks

46
02:36.840 --> 02:37.560
correctly

47
02:37.560 --> 02:42.040
and failing over the correct SVIs.

48
02:42.040 --> 02:46.240
Now we are going to elect an active note so let's say the note on the left is

49
02:46.240 --> 02:47.440
the active

50
02:47.440 --> 02:52.960
that makes the note on the right the standby and this is on a per group basis

51
02:52.960 --> 02:53.480
meaning that

52
02:53.480 --> 02:58.070
we could actually mix and match and by all rights we can and should mix and

53
02:58.070 --> 02:58.760
match.

54
02:58.760 --> 03:03.120
So we might actually have active and standby not by note here.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

54
02:58.760 --> 03:03.120
So we might actually have active and standby not by note here.

55
03:03.120 --> 03:06.880
We might say that I'm active for VLAN 10 on the left.

56
03:06.880 --> 03:12.480
I'm active for VLAN 20 on the right and then back to the left for VLAN 30

57
03:12.480 --> 03:13.600
something along

58
03:13.600 --> 03:19.750
those lines and importantly HSRP is going to use those exact terms for our two

59
03:19.750 --> 03:20.440
nodes.

60
03:20.440 --> 03:23.500
We're going to have active nodes and we're going to have standby nodes and

61
03:23.500 --> 03:24.640
these are the primary

62
03:24.640 --> 03:27.960
two roles.

63
03:27.960 --> 03:34.520
But we do have a third role and that third role is going to be listen mode.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

63
03:27.960 --> 03:34.520
But we do have a third role and that third role is going to be listen mode.

64
03:34.520 --> 03:39.600
Meaning that I might actually have a third device out here that has these three

65
03:39.600 --> 03:40.080
SVIs and

66
03:40.080 --> 03:44.230
it could all be part of the same network and at that point I'm going to be just

67
03:44.230 --> 03:44.720
sitting

68
03:44.720 --> 03:45.960
there listening to messages.

69
03:45.960 --> 03:51.300
I am neither the active nor the standby so just to put those standby labels up

70
03:51.300 --> 03:52.000
here.

71
03:52.000 --> 03:55.940
I'm neither the active nor the standby so I am just in listen mode for all of

72
03:55.940 --> 03:58.240
these groups.

73
03:58.240 --> 04:03.950
And if the active ever goes down then the standby will transition to active and
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

73
03:58.240 --> 04:03.950
And if the active ever goes down then the standby will transition to active and

74
04:03.950 --> 04:04.880
the listen will

75
04:04.880 --> 04:07.560
transition over to standby.

76
04:07.560 --> 04:12.240
If I have multiple listens then ultimately the one that has the best priority

77
04:12.240 --> 04:12.840
value is

78
04:12.840 --> 04:16.880
going to make the conversion up to standby.

79
04:16.880 --> 04:21.570
So we can have as many devices in the group as we want but all of them are

80
04:21.570 --> 04:22.880
going to be in

81
04:22.880 --> 04:28.040
listen mode if they're not voted as active or standby.

82
04:28.040 --> 04:32.080
And so that brings us to the question of well how are we choosing these roles.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

82
04:28.040 --> 04:32.080
And so that brings us to the question of well how are we choosing these roles.

83
04:32.080 --> 04:37.830
Well the way we do this is with a priority value and with the priority value on

84
04:37.830 --> 04:38.760
this one

85
04:38.760 --> 04:42.640
it's going to be that the highest priority wins.

86
04:42.640 --> 04:47.670
Now I know we learn a lot of priority values we learn about OSPF priorities, Hs

87
04:47.670 --> 04:49.080
rp priorities,

88
04:49.080 --> 04:53.040
spanning tree root priorities, all of these different priority values.

89
04:53.040 --> 04:55.760
Sometimes the highest one wins and sometimes the lowest one wins.

90
04:55.760 --> 04:58.280
So how do I keep track of this?

91
04:58.280 --> 05:03.490
Well I do have a helpful way of thinking about it that can help us to remember
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

91
04:58.280 --> 05:03.490
Well I do have a helpful way of thinking about it that can help us to remember

92
05:03.490 --> 05:04.200
but there

93
05:04.200 --> 05:08.120
are a couple of exceptions to it so I want to lay that caveat first.

94
05:08.120 --> 05:14.110
But the generally speaking if a protocol is layer 3 focused like OSPF, the IGRP

95
05:14.110 --> 05:15.600
, Hsrp,

96
05:15.600 --> 05:20.920
if it's layer 3 focused the higher number usually wins, if it's layer 2 focused

97
05:20.920 --> 05:21.160
talking

98
05:21.160 --> 05:26.030
about spanning tree protocol, ether channels, LECP, those kinds of things then

99
05:26.030 --> 05:26.640
usually the

100
05:26.640 --> 05:29.400
lowest priority value is going to win.

101
05:29.400 --> 05:35.760
So basically layer 3, higher wins, layer 2, lower wins.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

101
05:29.400 --> 05:35.760
So basically layer 3, higher wins, layer 2, lower wins.

102
05:35.760 --> 05:39.520
And again there might be a couple of exceptions out there but it's a lot easier

103
05:39.520 --> 05:40.200
to remember

104
05:40.200 --> 05:43.920
the exceptions and rather than try to remember all of them.

105
05:43.920 --> 05:48.640
So just kind of keep this in mind moving forward independent of even the FHRP

106
05:48.640 --> 05:49.640
conversation

107
05:49.640 --> 05:52.120
although naturally it applies right here.

108
05:52.120 --> 05:58.440
Now our priority value can be between 0 and 255 we get the full 8 bit range for

109
05:58.440 --> 05:59.120
that so I

110
05:59.120 --> 06:03.680
can go to the device that I want on a specific SVI.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

110
05:59.120 --> 06:03.680
can go to the device that I want on a specific SVI.

111
06:03.680 --> 06:07.360
Let's say I get on to the VLAN 30 interface here and I can configure it with a

112
06:07.360 --> 06:08.480
priority of

113
06:08.480 --> 06:12.400
255 as high as I want to go there.

114
06:12.400 --> 06:18.320
And for that matter by the way what happens if we have the same priority value?

115
06:18.320 --> 06:23.040
Well the tie breaker is going to be the highest IP address.

116
06:23.040 --> 06:27.680
So in theory we don't have duplicate IP addresses on the network that would be

117
06:27.680 --> 06:29.800
pretty bad.

118
06:29.800 --> 06:35.050
So somebody is going to have to win the tie breaker as far as having a higher
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

118
06:29.800 --> 06:35.050
So somebody is going to have to win the tie breaker as far as having a higher

119
06:35.050 --> 06:35.920
IP address.

120
06:35.920 --> 06:40.110
So from here we can get into other configurations and certainly a lot of this

121
06:40.110 --> 06:41.480
involves configurations,

122
06:41.480 --> 06:46.370
the group ID, the priority value and keep in mind that at this point in the

123
06:46.370 --> 06:47.200
blue print

124
06:47.200 --> 06:51.840
we're really focusing more on general knowledge, black boarding here.

125
06:51.840 --> 06:57.790
We're just kind of talking about all the different components of our FHRP's

126
06:57.790 --> 06:59.280
later on when we

127
06:59.280 --> 07:02.940
get into the configuration section we're going to be putting our hands on the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

127
06:59.280 --> 07:02.940
get into the configuration section we're going to be putting our hands on the

128
07:02.940 --> 07:04.440
CLI and configuring

129
07:04.440 --> 07:07.320
HSRP and all these other FHRP's.

130
07:07.320 --> 07:10.170
So for now we're going to talk about some of the configuration parameters and

131
07:10.170 --> 07:10.680
then later

132
07:10.680 --> 07:16.660
on we're going to refresh our knowledge on some of this as we actually

133
07:16.660 --> 07:17.880
configure devices

134
07:17.880 --> 07:21.040
to perform fail over using HSRP.

135
07:21.040 --> 07:25.310
But as far as some of the other configuration parameters go and again we do

136
07:25.310 --> 07:26.080
have a few that

137
07:26.080 --> 07:31.970
we've already talked about here but we do have the ability to change the timers
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

137
07:26.080 --> 07:31.970
we've already talked about here but we do have the ability to change the timers

138
07:31.970 --> 07:32.000
.

139
07:32.000 --> 07:35.920
The timers are how we track whether a device has gone down or not.

140
07:35.920 --> 07:40.640
So generally speaking we have a or by default I suppose we have a three seconds

141
07:40.640 --> 07:47.120
hello timer and we have a 10 second hold timer.

142
07:47.120 --> 07:51.460
So just like with a lot of other protocols if you've got two devices sending

143
07:51.460 --> 07:52.080
messages

144
07:52.080 --> 07:57.310
to one another we're going to send the hello message or we're going to send a

145
07:57.310 --> 07:57.760
message

146
07:57.760 --> 07:59.280
every hello timer.

147
07:59.280 --> 08:02.250
So we're sending it every three seconds three seconds later I'll send another
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

147
07:59.280 --> 08:02.250
So we're sending it every three seconds three seconds later I'll send another

148
08:02.250 --> 08:02.680
one three

149
08:02.680 --> 08:04.920
seconds later I'll send another one.

150
08:04.920 --> 08:09.810
And if I don't receive one for the hold timer so now it's gone 10 seconds by

151
08:09.810 --> 08:10.440
default

152
08:10.440 --> 08:13.880
again without me receiving one from the other side I'm going to assume the

153
08:13.880 --> 08:15.800
other side is down.

154
08:15.800 --> 08:20.230
Now yes this does mean that I have to wait 10 full seconds to decide that the

155
08:20.230 --> 08:21.040
active has

156
08:21.040 --> 08:25.090
gone down and so we might want to go a little bit faster than that and so we do

157
08:25.090 --> 08:25.920
have access

158
08:25.920 --> 08:30.840
to millisecond timers but only with HSRP version two.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

158
08:25.920 --> 08:30.840
to millisecond timers but only with HSRP version two.

159
08:30.840 --> 08:35.660
So one reason why we want to go with HSRP version two is to make sure that we

160
08:35.660 --> 08:36.720
can go with

161
08:36.720 --> 08:41.510
smaller timers and in more advanced configurations as well we might actually

162
08:41.510 --> 08:42.560
end up deploying

163
08:42.560 --> 08:47.470
bidirectional forwarding detection or BFD which is a way a very lightweight

164
08:47.470 --> 08:48.560
mechanism that

165
08:48.560 --> 08:53.040
allows us to very quickly detect failures and this can be placed over routing

166
08:53.040 --> 08:53.680
protocols

167
08:53.680 --> 08:57.510
and it can actually be placed over HSRP as well at which point we could use the

168
08:57.510 --> 08:58.040
default

169
08:58.040 --> 09:02.920
timers and rely on BFD to detect the faster failover.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

169
08:58.040 --> 09:02.920
timers and rely on BFD to detect the faster failover.

170
09:02.920 --> 09:06.460
So keep that in mind as well that we'll see BFD showing up throughout the

171
09:06.460 --> 09:07.280
course but either

172
09:07.280 --> 09:11.700
way we can still just configure HSRP with millisecond timers detect it very

173
09:11.700 --> 09:12.860
quickly using

174
09:12.860 --> 09:19.840
HSRP mechanisms as far as other configurations we have preemption and by the

175
09:19.840 --> 09:21.320
way preemption

176
09:21.320 --> 09:27.760
is disabled by default that is important for us to know we need to make sure

177
09:27.760 --> 09:28.480
that if we

178
09:28.480 --> 09:33.480
do want preemption enabled like we described in the previous video that we have
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

178
09:28.480 --> 09:33.480
do want preemption enabled like we described in the previous video that we have

179
09:33.480 --> 09:34.160
to enable

180
09:34.160 --> 09:39.330
it and so that's a consideration there and we also have authentication

181
09:39.330 --> 09:40.760
authentication is

182
09:40.760 --> 09:46.300
important because the winner of HSRP negotiations is declared the default

183
09:46.300 --> 09:47.700
gateway and we want

184
09:47.700 --> 09:54.600
to prevent our threat actors from performing man in the middle attacks.

185
09:54.600 --> 09:59.570
So one way they could do a man in the middle attack is to send bad HSRP

186
09:59.570 --> 10:01.100
messages with a very
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

186
09:59.570 --> 10:01.100
messages with a very

187
10:01.100 --> 10:07.840
high priority say my priority is 255 and hope I become the default gateway.

188
10:07.840 --> 10:11.480
If I become the default gateway then everybody is going to send their messages

189
10:11.480 --> 10:12.080
to me and then

190
10:12.080 --> 10:16.640
I can send them out and that's the man in the middle attack we want to prevent.

191
10:16.640 --> 10:18.000
How do we prevent it though?

192
10:18.000 --> 10:21.960
Well the way we do it is by authenticating our messages HSRP allows us to

193
10:21.960 --> 10:22.820
configure a

194
10:22.820 --> 10:29.560
password that is hash and then we can validate that the person claiming to be a

195
10:29.560 --> 10:30.300
high priority
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

195
10:29.560 --> 10:30.300
high priority

196
10:30.300 --> 10:33.380
HSRP node actually belongs on the network.