WEBVTT

1
00:00.000 --> 00:04.920
When we look at first-hop redundancy protocols, most of our focus is going to

2
00:04.920 --> 00:07.000
be on direct failures.

3
00:07.000 --> 00:12.030
We've given the example every time of the active node going down, for example,

4
00:12.030 --> 00:13.000
or maybe the interface fails,

5
00:13.000 --> 00:18.000
or something directly in the path goes down and prevents gateway access.

6
00:18.000 --> 00:25.000
But what about an indirect failure, especially in the upstream direction?

7
00:25.000 --> 00:30.000
FHRP's by themselves aren't going to necessarily help us out here.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

8
00:30.000 --> 00:36.000
And this can actually lead to at a minimum inefficient forwarding of packets,

9
00:36.000 --> 00:41.630
meaning that we might have to receive a packet on the active node and then send

10
00:41.630 --> 00:43.000
it over to the backup node anyways,

11
00:43.000 --> 00:49.000
but at worst, it can actually result in the black holding of traffic.

12
00:49.000 --> 00:54.790
And so we need to address the fact that an indirect upstream failure could

13
00:54.790 --> 00:58.000
cause us issues in our FHRP environment.

14
00:58.000 --> 01:00.000
So let's see this as an example.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

15
01:00.000 --> 01:04.540
Usually what we're going to talk about here is a pair of routers running an FH

16
01:04.540 --> 01:05.000
RP.

17
01:05.000 --> 01:09.000
We'll just call this the active and the standby.

18
01:09.000 --> 01:14.300
So in this case, just like usual, we've got active standby, running HSRP, life

19
01:14.300 --> 01:15.000
is good.

20
01:15.000 --> 01:20.000
We have our endpoints down here and they're all forwarding up to the active.

21
01:20.000 --> 01:24.260
And we know if the active goes down, the standby takes over, we redirect it at

22
01:24.260 --> 01:27.000
layer two to the standby gateway.

23
01:27.000 --> 01:30.000
So that would be the direct failure.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

24
01:30.000 --> 01:35.300
But now, let's consider the possibility that both of these routers have

25
01:35.300 --> 01:39.000
upstream connections to a layer three environment.

26
01:39.000 --> 01:43.580
This could be our network core, for example, where it could be a single

27
01:43.580 --> 01:45.000
upstream router.

28
01:45.000 --> 01:48.000
It could be a bunch of upstream routers, same hardware, different hardware,

29
01:48.000 --> 01:49.000
either way.

30
01:49.000 --> 01:53.130
We are talking about a layer three converged environment with routing protocols

31
01:53.130 --> 01:54.000
and the like.

32
01:54.000 --> 02:00.160
So now, let's say that we have that indirect upstream failure, meaning that it
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

32
01:54.000 --> 02:00.160
So now, let's say that we have that indirect upstream failure, meaning that it

33
02:00.160 --> 02:04.000
's not that we lost the node or the interface on the node,

34
02:04.000 --> 02:09.000
but rather we lost the connection to the upstream network.

35
02:09.000 --> 02:12.740
Maybe that was the failure of the link. Maybe there's a router and a router

36
02:12.740 --> 02:16.000
here and we lost access to this router here.

37
02:16.000 --> 02:20.260
And so the active node no longer has a direct link to the layer three

38
02:20.260 --> 02:23.000
environment, but the standby does.

39
02:23.000 --> 02:28.920
Well, by default, FHRP's are going to look at this and say, "All right, well,

40
02:28.920 --> 02:33.000
that's well and good, except what do I care most about?
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

40
02:28.920 --> 02:33.000
that's well and good, except what do I care most about?

41
02:33.000 --> 02:38.520
Whether my interface is online, and because my interface is online, we're not

42
02:38.520 --> 02:40.000
going to perform a failover."

43
02:40.000 --> 02:45.000
Meanwhile, what is the traffic path we're going to take?

44
02:45.000 --> 02:48.980
Well, we're going to perform our ARP if we need to and layer two is going to

45
02:48.980 --> 02:51.000
forward us to the active.

46
02:51.000 --> 02:56.380
And then the active, assuming it's running routing protocols out this layer two

47
02:56.380 --> 03:00.000
domain, is going to forward us over to the standby.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

48
03:00.000 --> 03:05.000
And then we get forwarded upstream from a layer three perspective.

49
03:05.000 --> 03:08.590
Interestingly, the return traffic doesn't quite follow the same pattern because

50
03:08.590 --> 03:12.650
of the directly attached route when the return traffic comes back to the

51
03:12.650 --> 03:13.000
standby.

52
03:13.000 --> 03:18.000
The standby is going to immediately forward it down to the endpoint.

53
03:18.000 --> 03:22.470
And so we not only have an inefficient path going outbound, we have asymmetric

54
03:22.470 --> 03:28.300
routing happening because the forwarding path for the initial traffic and the

55
03:28.300 --> 03:29.000
return traffic

56
03:29.000 --> 03:36.180
look very different. So this is a situation where we have a massive amount of
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

56
03:29.000 --> 03:36.180
look very different. So this is a situation where we have a massive amount of

57
03:36.180 --> 03:38.000
inefficiency.

58
03:38.000 --> 03:44.590
We're going to have to come up with a way for us to failover even if the active

59
03:44.590 --> 03:46.000
is online.

60
03:46.000 --> 03:50.240
Now we mentioned this could perform black holding of traffic as well. And that

61
03:50.240 --> 03:56.000
could absolutely happen because what if we don't actually have routing?

62
03:56.000 --> 04:01.110
So maybe we're running OSPF in this environment. So OSPF is running upstream
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

62
03:56.000 --> 04:01.110
So maybe we're running OSPF in this environment. So OSPF is running upstream

63
04:01.110 --> 04:06.000
this way, but we have passive interface on our downstream interfaces.

64
04:06.000 --> 04:11.800
Well, at that point, we don't actually have OSPF routes coming in, which means

65
04:11.800 --> 04:16.930
that I'm going to send my traffic up to the active and the active is going to

66
04:16.930 --> 04:19.000
just drop it because it doesn't have a route.

67
04:19.000 --> 04:23.610
It lost all of its routes upstream and we don't have a routing relationship

68
04:23.610 --> 04:28.560
with the standby. So even worse, this truly could cause us to start black

69
04:28.560 --> 04:30.000
holding our traffic.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

70
04:30.000 --> 04:35.150
And that is absolutely the worst case scenario here. For any reason, we're

71
04:35.150 --> 04:39.000
dropping traffic at this point. We know that we have a big problem.

72
04:39.000 --> 04:43.840
And the crazy thing in all of this is that it doesn't require something that's

73
04:43.840 --> 04:48.950
completely unlikely to happen, but rather just a simple interface going down on

74
04:48.950 --> 04:53.000
the upstream link or a device upstream failing.

75
04:53.000 --> 04:56.650
We've got all of that's what caused this. And we've got all the redundancy of

76
04:56.650 --> 05:00.000
our routing protocols. We've got all the gateway redundancy of our FHRP.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

77
05:00.000 --> 05:04.880
But as configured, a simple interface failure could result in all of our

78
05:04.880 --> 05:09.810
traffic getting black hold. Imagine trying to explain that to management after

79
05:09.810 --> 05:13.120
we justify the cost of the redundant gateways and the deployment of all of

80
05:13.120 --> 05:14.000
these protocols.

81
05:14.000 --> 05:19.330
It's not going to be a fun conversation. So what do we have as a solution to

82
05:19.330 --> 05:20.000
this?

83
05:20.000 --> 05:31.000
Well, fortunately, we have one and it is known as FHRP object tracking.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

83
05:20.000 --> 05:31.000
Well, fortunately, we have one and it is known as FHRP object tracking.

84
05:31.000 --> 05:42.000
FHRP object tracking is going to allow for the detection of an upstream issue.

85
05:42.000 --> 05:50.650
And at that point, we're going to trigger a failover. Now what's fascinating

86
05:50.650 --> 05:55.000
about this is in this case, our active node is still online.

87
05:55.000 --> 06:06.000
We're going to failover from the active and importantly, still online node.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

87
05:55.000 --> 06:06.000
We're going to failover from the active and importantly, still online node.

88
06:06.000 --> 06:14.000
So this is a voluntary, a voluntary surrender of the active role.

89
06:14.000 --> 06:21.310
Now, a natural question at that point is how, how can we defer our role to the

90
06:21.310 --> 06:23.000
other device?

91
06:23.000 --> 06:28.490
And the answer here is going to involve two existing mechanisms across our FHRP

92
06:28.490 --> 06:29.000
's.

93
06:29.000 --> 06:39.000
First of all, the priority value and second of all, the concept of preemption.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

93
06:29.000 --> 06:39.000
First of all, the priority value and second of all, the concept of preemption.

94
06:39.000 --> 06:43.820
So remember how priority works. If I have my two nodes here, I'm going to

95
06:43.820 --> 06:45.000
assign a priority value.

96
06:45.000 --> 06:52.000
Now, the default values for HSRP and VRRP are going to be 100.

97
06:52.000 --> 06:57.010
So if I have a priority of 100 on one side, I could lower the priority of the

98
06:57.010 --> 06:59.000
other side to let's say 90.

99
06:59.000 --> 07:02.810
And that means that the left side will become the active because it has a
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

99
06:59.000 --> 07:02.810
And that means that the left side will become the active because it has a

100
07:02.810 --> 07:04.000
better priority.

101
07:04.000 --> 07:08.360
And so that's the how priority works and how the election of the active node

102
07:08.360 --> 07:09.000
works.

103
07:09.000 --> 07:13.950
Then from a preemption perspective, if this node were to go down, the active

104
07:13.950 --> 07:18.000
will fire up on the right side, but the priority value is still 90.

105
07:18.000 --> 07:25.000
So that when the active node comes back online and it has preemption enabled,

106
07:25.000 --> 07:30.000
it's going to be able to take back over because it has a higher priority level.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

107
07:30.000 --> 07:34.000
Now, in this example, the priority level remains static.

108
07:34.000 --> 07:42.000
And that's typically how we deploy our FHRP's is with a static priority value.

109
07:42.000 --> 07:47.710
But what happens if priorities start to change? And that's exactly the

110
07:47.710 --> 07:53.650
mechanism we're going to use here is we're going to use dynamic priority values

111
07:53.650 --> 07:54.000
.

112
07:54.000 --> 07:58.520
So now look at the same situation. Let's say that we have preemption actually

113
07:58.520 --> 08:00.000
enabled on both sides.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

114
08:00.000 --> 08:04.630
Normally, we wouldn't need preemption enabled on the backup node because its

115
08:04.630 --> 08:06.000
priority is lower.

116
08:06.000 --> 08:10.030
But it will never be able to preempt with a lower priority. But what happens if

117
08:10.030 --> 08:12.000
we both have upstream connections?

118
08:12.000 --> 08:17.310
This one goes down and we decide because that one went down, we're going to

119
08:17.310 --> 08:20.000
change our priority value to 70.

120
08:20.000 --> 08:25.090
Well, now not only do I have preemption enabled, but I do have the higher

121
08:25.090 --> 08:31.560
priority value, which allows me to take over as the active with my better
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

121
08:25.090 --> 08:31.560
priority value, which allows me to take over as the active with my better

122
08:31.560 --> 08:33.000
priority.

123
08:33.000 --> 08:38.000
Now, if that link comes back online, I'll probably go back to a priority of 100

124
08:38.000 --> 08:41.000
and because I have preemption, I can take back over as the active.

125
08:41.000 --> 08:45.000
But the idea here is that our priority values can be a little more fluid.

126
08:45.000 --> 08:50.000
They can increase or decrease depending on the scenario and especially based on

127
08:50.000 --> 08:52.000
what's happening upstream.

128
08:52.000 --> 08:58.270
So the way that we're going to perform this mechanism set is we're going to

129
08:58.270 --> 09:01.000
again use what we call object tracking.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

129
08:58.270 --> 09:01.000
again use what we call object tracking.

130
09:01.000 --> 09:06.000
I'm going to create an object in the system.

131
09:06.000 --> 09:11.210
And this object is going to be associated with a basically a Boolean or a true

132
09:11.210 --> 09:13.000
and false statement.

133
09:13.000 --> 09:17.000
We'll just say it's up or down.

134
09:17.000 --> 09:23.060
And if it's down, we're going to have a priority decrement value associated

135
09:23.060 --> 09:24.000
with it.

136
09:24.000 --> 09:31.080
The word decrement simply means I'm going to decrease something. It's the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

136
09:24.000 --> 09:31.080
The word decrement simply means I'm going to decrease something. It's the

137
09:31.080 --> 09:32.000
opposite of incrementing. If I want to increment something, I increase it.

138
09:32.000 --> 09:35.000
Decoramenting is decreasing it.

139
09:35.000 --> 09:39.310
So I might say, for example, that if that link goes down, then I would decre

140
09:39.310 --> 09:41.000
ment my priority by 30.

141
09:41.000 --> 09:47.320
And that would take me from that 100 to 70. And when the link comes back online

142
09:47.320 --> 09:50.000
, I'm back at 100.

143
09:50.000 --> 09:54.200
So then the question is simply, what are these objects? We actually have quite

144
09:54.200 --> 09:56.000
a few options available to us.

145
09:56.000 --> 10:04.000
First of all, we can simply track the line protocol of an interface.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

145
09:56.000 --> 10:04.000
First of all, we can simply track the line protocol of an interface.

146
10:04.000 --> 10:09.000
This would be an interface up down status.

147
10:09.000 --> 10:13.860
Meaning that if I actually lose this link, or maybe over here with this example

148
10:13.860 --> 10:16.000
, the link that we said went down,

149
10:16.000 --> 10:21.340
if I lose a link, I detect that. It's direct on me. It's upstream, but it's

150
10:21.340 --> 10:23.000
still a direct failure at that point.

151
10:23.000 --> 10:26.710
And now I can say that, all right, I've lost a connection. I should go ahead

152
10:26.710 --> 10:29.000
and decrement that by whatever I have configured.

153
10:29.000 --> 10:36.000
So that's option number one. Option number two is I can track reachability.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

153
10:29.000 --> 10:36.000
So that's option number one. Option number two is I can track reachability.

154
10:36.000 --> 10:41.000
So I can figure out if I can reach a particular IP address.

155
10:41.000 --> 10:44.890
This will be useful in the scenario, like we described over here, really the

156
10:44.890 --> 10:50.080
black hole scenario, where I actually lost my access to the rest of the layer

157
10:50.080 --> 10:51.000
three network.

158
10:51.000 --> 10:54.630
I could pick an IP address up there, and I could say, hey, I want to make sure

159
10:54.630 --> 10:59.040
that I can reach this. And if I can't great, and if I can't, I need to decre

160
10:59.040 --> 11:01.000
ment my priority value.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

160
10:59.040 --> 11:01.000
ment my priority value.

161
11:01.000 --> 11:03.000
So that would be a second option.

162
11:03.000 --> 11:07.600
A third option is I can actually look at my routing table directly. And so I

163
11:07.600 --> 11:12.360
can check for route availability. Does a route exist in my routing table? If so

164
11:12.360 --> 11:14.000
, our object is up.

165
11:14.000 --> 11:18.000
And if the route doesn't exist, our object is down.

166
11:18.000 --> 11:22.880
And lastly, we have a whole other world available at our fingertips. It says go

167
11:22.880 --> 11:27.000
refers to as IP service level agreement or IPSLA.

168
11:27.000 --> 11:31.380
And IPSLA is its own configuration set. It allows me to do all kinds of
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

168
11:27.000 --> 11:31.380
And IPSLA is its own configuration set. It allows me to do all kinds of

169
11:31.380 --> 11:36.150
different performance checks and ultimately trying to establish whether a

170
11:36.150 --> 11:39.000
service level agreement has been violated.

171
11:39.000 --> 11:45.190
And I can use TCP tests, UDP tests, ping tests, all kinds of things. And when I

172
11:45.190 --> 11:50.000
'm using this as my option, so we've got our four different options here.

173
11:50.000 --> 11:54.390
And using IPSLA as my option, it's either going to be in an upstate or a down

174
11:54.390 --> 11:59.470
state, which will match to the object. So I have to configure this object that's

175
11:59.470 --> 12:02.000
going to be at the heart of all of this.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

175
11:59.470 --> 12:02.000
going to be at the heart of all of this.

176
12:02.000 --> 12:08.110
And then in my FHRP configuration, I perform my decrement command and I relate

177
12:08.110 --> 12:10.000
it back to this object.

178
12:10.000 --> 12:15.600
So it's a mixture of several different mechanisms here. We're leveraging FHRP

179
12:15.600 --> 12:21.160
mechanisms in our ability to dynamically change priority and use preemption in

180
12:21.160 --> 12:24.000
order to take over as an active node.

181
12:24.000 --> 12:30.360
And then we're also using object tracking and FHRP decrements in order to make
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

181
12:24.000 --> 12:30.360
And then we're also using object tracking and FHRP decrements in order to make

182
12:30.360 --> 12:33.000
the priority values dynamic.

183
12:33.000 --> 12:37.220
And in the event that my network is impaired, and again, meaning I'm not down

184
12:37.220 --> 12:41.530
necessarily, you might be black holding, but we might also just be running in

185
12:41.530 --> 12:43.000
an efficient manner.

186
12:43.000 --> 12:48.110
Then at that point, our FHRP object tracking can come in here, detect the issue

187
12:48.110 --> 12:53.000
and perform a failover thereby keeping our network in really good shape,

188
12:53.000 --> 12:56.000
despite the indirect or upstream outage.