WEBVTT

1
00:00.000 --> 00:07.000
So, one thing that we may have noticed is that HsRP and VRRP, these are only

2
00:07.000 --> 00:08.160
going to support

3
00:08.160 --> 00:14.910
one active node. Whether that's HsRP active or VRRP master, but we're only

4
00:14.910 --> 00:15.560
forwarding

5
00:15.560 --> 00:21.390
out one device. So, if I have two devices and there are just routers with layer

6
00:21.390 --> 00:21.880
three

7
00:21.880 --> 00:26.710
interfaces, then all of my traffic is going to go up this way towards the

8
00:26.710 --> 00:27.640
active node,

9
00:27.640 --> 00:31.210
assuming that's the active node on the left there, leaving this node on the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

9
00:27.640 --> 00:31.210
assuming that's the active node on the left there, leaving this node on the

10
00:31.210 --> 00:31.960
right as being

11
00:31.960 --> 00:39.840
relatively idle. Now, part of this can be resolved by leveraging HsRP and VRRP

12
00:39.840 --> 00:40.200
with

13
00:40.200 --> 00:45.270
layer three switches. Because, as we mentioned before, we might have a slew of

14
00:45.270 --> 00:46.480
SVIs. We could

15
00:46.480 --> 00:51.800
have dozens of these SVIs in here. We're connecting our devices via layer two.

16
00:51.800 --> 00:52.200
And so,

17
00:52.200 --> 00:57.610
we recognize that these two SVIs are going to be part of one group. And so, let

18
00:57.610 --> 00:57.960
's say

19
00:57.960 --> 01:04.260
the active is on the left for this particular set of SVIs. But then, we pair up
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

19
00:57.960 --> 01:04.260
the active is on the left for this particular set of SVIs. But then, we pair up

20
01:04.260 --> 01:04.680
these

21
01:04.680 --> 01:09.150
SVIs. So, this can be a completely different VLAN and the active for that VLANs

22
01:09.150 --> 01:09.480
on the

23
01:09.480 --> 01:14.710
left. And we alternate back and forth and we can divide up our VLANs in the

24
01:14.710 --> 01:15.560
same way we

25
01:15.560 --> 01:19.490
like to do with spanning tree protocol routes. And so, this does give us some

26
01:19.490 --> 01:19.960
amount of

27
01:19.960 --> 01:25.900
load balancing. But we still can't have more than one active device at a time

28
01:25.900 --> 01:26.320
using these

29
01:26.320 --> 01:31.520
two protocols. And this is going to lead us to a conversation around Cisco's
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

29
01:26.320 --> 01:31.520
two protocols. And this is going to lead us to a conversation around Cisco's

30
01:31.520 --> 01:32.560
gateway load

31
01:32.560 --> 01:41.960
balancing protocol or GLBP. GLBP was designed to give us multiple active

32
01:41.960 --> 01:44.240
forwarders, referring

33
01:44.240 --> 01:55.190
to our gateways. So, how exactly does this work? Well, GLBP is just going to

34
01:55.190 --> 01:56.360
allow us to

35
01:56.360 --> 02:01.940
have up to four different devices that can serve as gateways. So, all of these
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

35
01:56.360 --> 02:01.940
have up to four different devices that can serve as gateways. So, all of these

36
02:01.940 --> 02:03.200
would have the same

37
02:03.200 --> 02:08.730
SVI. And all of them are capable of forwarding. And so, I want to load balance

38
02:08.730 --> 02:09.360
the traffic

39
02:09.360 --> 02:15.100
as I get my client traffic in here. So, this is my set of endpoints. And we're

40
02:15.100 --> 02:15.760
going to use

41
02:15.760 --> 02:20.650
some form of load balancing mechanism to direct these endpoints to these four

42
02:20.650 --> 02:21.400
different

43
02:21.400 --> 02:27.270
devices, all sharing one virtual IP address. We have one virtual IP address. We

44
02:27.270 --> 02:27.920
're forwarding

45
02:27.920 --> 02:32.800
to four different devices. And those are now all active in this environment.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

45
02:27.920 --> 02:32.800
to four different devices. And those are now all active in this environment.

46
02:32.800 --> 02:33.280
Now, first

47
02:33.280 --> 02:39.490
glance, GLBP feels like, oh, this is the superior version of HSRP. Or we might

48
02:39.490 --> 02:41.360
as well not use HSRP

49
02:41.360 --> 02:47.180
and VRRP anymore. The reality is that GLBP never really took off. It does have

50
02:47.180 --> 02:47.640
the ability

51
02:47.640 --> 02:51.920
to load balance and it supports up to four active forwarders at once. And that

52
02:51.920 --> 02:52.640
's great.

53
02:52.640 --> 02:57.480
But it was a much more complex configuration. And furthermore, what we found in

54
02:57.480 --> 02:57.960
most of

55
02:57.960 --> 03:02.940
our environments is we didn't need more than two different gateways. So, we'd
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

55
02:57.960 --> 03:02.940
our environments is we didn't need more than two different gateways. So, we'd

56
03:02.940 --> 03:03.880
have a pair of

57
03:03.880 --> 03:08.090
layer three switches serving as the gateways using our SVIs and our VLAN

58
03:08.090 --> 03:09.920
interfaces. And so,

59
03:09.920 --> 03:14.110
this form of load balancing up here, just splitting the VLANs between the two,

60
03:14.110 --> 03:14.600
was a whole

61
03:14.600 --> 03:19.230
lot simpler for most network engineers to deploy. And for that matter, troubles

62
03:19.230 --> 03:19.720
hoot when

63
03:19.720 --> 03:24.640
there are issues relative to deploying a more complex protocol like GLBP. In

64
03:24.640 --> 03:25.280
fact, these

65
03:25.280 --> 03:31.360
days, Cisco's Nexus platform, which is a data center only application or switch
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

65
03:25.280 --> 03:31.360
days, Cisco's Nexus platform, which is a data center only application or switch

66
03:31.360 --> 03:32.080
, we should

67
03:32.080 --> 03:36.360
only be deploying XSWitches into the data center. But those switches don't even

68
03:36.360 --> 03:37.760
support GLBP,

69
03:37.760 --> 03:41.970
even though they're Cisco switches. And this is a Cisco protocol. So, I don't

70
03:41.970 --> 03:42.400
want to take

71
03:42.400 --> 03:45.950
the wind out of our sales here. I mean, GLBP is something we should study and

72
03:45.950 --> 03:46.600
be able to

73
03:46.600 --> 03:51.570
configure. But from a real world perspective, I wouldn't expect to see a whole

74
03:51.570 --> 03:52.520
lot of GLBP

75
03:52.520 --> 03:56.710
out there and I don't want our takeaway out of this conversation to be, oh, I'm

76
03:56.710 --> 03:56.960
going to

77
03:56.960 --> 04:03.020
go replace my HSRP environment with GLBP because we might not get a whole lot
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

77
03:56.960 --> 04:03.020
go replace my HSRP environment with GLBP because we might not get a whole lot

78
04:03.020 --> 04:04.000
of benefit

79
04:04.000 --> 04:08.390
from it. And we might be creating more complexity and a worse ability to

80
04:08.390 --> 04:09.480
support our network

81
04:09.480 --> 04:14.320
in the event of having problems. So, one thing that is worth pointing out, I've

82
04:14.320 --> 04:14.560
already

83
04:14.560 --> 04:20.220
mentioned it, but this is a Cisco proprietary protocol. This is not industry

84
04:20.220 --> 04:20.760
standard.

85
04:20.760 --> 04:25.760
This was created by Cisco. Somebody thought they had a great idea and by all

86
04:25.760 --> 04:26.520
right, it is.

87
04:26.520 --> 04:29.900
It's a really neat idea, especially when we break down how it works. It's

88
04:29.900 --> 04:31.000
really impressive,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

88
04:29.900 --> 04:31.000
really impressive,

89
04:31.000 --> 04:35.460
but it's something that didn't really take off in our industry. Now, when we

90
04:35.460 --> 04:36.240
talk about

91
04:36.240 --> 04:42.590
GLBP roles, we're going to find that we need new roles. We don't use active and

92
04:42.590 --> 04:43.000
standby

93
04:43.000 --> 04:48.070
or master and backup here. Instead, we're going to have two new roles. We're

94
04:48.070 --> 04:48.480
going to have

95
04:48.480 --> 04:58.160
the active virtual gateway, which is abbreviated as the AVG. And importantly,

96
04:58.160 --> 04:58.640
we're going to

97
04:58.640 --> 05:08.280
have one of these. And then we're also going to have the role of active virtual
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

97
04:58.640 --> 05:08.280
have one of these. And then we're also going to have the role of active virtual

98
05:08.280 --> 05:08.640
forwarder.

99
05:08.640 --> 05:14.920
And that would be abbreviated as AVF. And we can have many AVFs, including by

100
05:14.920 --> 05:15.640
the way,

101
05:15.640 --> 05:21.670
the AVG. When we break this down from a high level, the AVG is going to be

102
05:21.670 --> 05:22.920
responsible for

103
05:22.920 --> 05:28.220
managing GLBP from a control plane perspective. So we need one device to sort

104
05:28.220 --> 05:28.960
of be managing

105
05:28.960 --> 05:33.920
what's happening here. Meanwhile, the AVFs, these are all of the gateways that
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

105
05:28.960 --> 05:33.920
what's happening here. Meanwhile, the AVFs, these are all of the gateways that

106
05:33.920 --> 05:34.600
are capable

107
05:34.600 --> 05:40.470
of performing data forwarding as the name implies. So in our case down here, we

108
05:40.470 --> 05:41.600
might have the

109
05:41.600 --> 05:49.340
AVG all the way on the left, but all of these devices are going to be AVFs,

110
05:49.340 --> 05:50.240
including the

111
05:50.240 --> 05:55.710
AVG. It's going to hold both of those roles. Now, we might be looking at this

112
05:55.710 --> 05:56.320
wondering,

113
05:56.320 --> 06:01.120
what is this load balancing mechanism? How do we make it so that some endpoints
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

113
05:56.320 --> 06:01.120
what is this load balancing mechanism? How do we make it so that some endpoints

114
06:01.120 --> 06:01.560
use this

115
06:01.560 --> 06:05.820
device on the left, some endpoints use this device on the right? What exactly

116
06:05.820 --> 06:06.320
are we doing

117
06:06.320 --> 06:12.930
there? Well, the way we do this is actually fairly simple. We apply a different

118
06:12.930 --> 06:15.280
virtual MAC address

119
06:15.280 --> 06:25.510
per AVF. Now remember, we are still sharing a virtual IP address. So this gets

120
06:25.510 --> 06:26.640
shared among

121
06:26.640 --> 06:30.080
all of our devices. And that makes sense because all of our endpoints need to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

121
06:26.640 --> 06:30.080
all of our devices. And that makes sense because all of our endpoints need to

122
06:30.080 --> 06:30.800
be configured

123
06:30.800 --> 06:34.270
with a single default gateway. We're not load balancing by giving them

124
06:34.270 --> 06:36.280
different IP addresses.

125
06:36.280 --> 06:40.720
We could do that without GLBP. We just have to deal with failures, which is not

126
06:40.720 --> 06:42.240
so good. But

127
06:42.240 --> 06:47.180
GLBP allows us to share a virtual IP address. And yet, we're going to have,

128
06:47.180 --> 06:48.240
again, maybe

129
06:48.240 --> 06:53.730
four, I'm going to say many here, I suppose, but up to four different AVFs each

130
06:53.730 --> 06:54.400
with their

131
06:54.400 --> 07:00.510
own virtual MAC address. Furthermore, because the AVG is responsible for the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

131
06:54.400 --> 07:00.510
own virtual MAC address. Furthermore, because the AVG is responsible for the

132
07:00.510 --> 07:02.480
control mechanisms,

133
07:02.480 --> 07:09.100
it's going to perform all of the ARP responses. And it's going to perform the

134
07:09.100 --> 07:09.800
load balancing

135
07:09.800 --> 07:15.500
by deciding which virtual MAC address to hand to each endpoint. Now, let's go

136
07:15.500 --> 07:15.920
ahead and

137
07:15.920 --> 07:20.090
walk through an example here. So let's say that we have a device come online

138
07:20.090 --> 07:21.120
and we have

139
07:21.120 --> 07:26.900
this GLBP configured, the virtual IP addresses dot 254. And so we have our

140
07:26.900 --> 07:27.720
gateway configured

141
07:27.720 --> 07:33.960
is whatever the subnet is dot 254. And I need to know what the MAC address is.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

141
07:27.720 --> 07:33.960
is whatever the subnet is dot 254. And I need to know what the MAC address is.

142
07:33.960 --> 07:34.360
How do I do

143
07:34.360 --> 07:39.960
that? Well, of course, I'm going to send an ARP request out into the network.

144
07:39.960 --> 07:40.280
Now, we just

145
07:40.280 --> 07:45.530
said that the AVG is going to perform all ARP responses. An ARP is a broadcast

146
07:45.530 --> 07:46.200
packet. And

147
07:46.200 --> 07:50.980
so that means that all of these devices are going to receive the ARP response

148
07:50.980 --> 07:51.700
or the ARP

149
07:51.700 --> 07:58.750
request rather for dot 254. So they all receive the request, but only the AVG

150
07:58.750 --> 08:01.020
sends the response.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

150
07:58.750 --> 08:01.020
sends the response.

151
08:01.020 --> 08:05.000
And so the question is what is the virtual MAC address that we're responding

152
08:05.000 --> 08:06.340
with? Well,

153
08:06.340 --> 08:10.520
the AVG can use one of its load balancing methods. And we'll talk about those

154
08:10.520 --> 08:11.540
in a moment

155
08:11.540 --> 08:18.580
to decide which one of these AVS AVFs to provide from a VMAQ perspective. So

156
08:18.580 --> 08:19.020
let's say we have

157
08:19.020 --> 08:25.870
our four different VMAQs. And we will just say that they end in dot a, I guess

158
08:25.870 --> 08:27.820
not dot a, but the

159
08:27.820 --> 08:32.700
end of the MAC address is with an a here and then ends with a b ends with a c
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

159
08:27.820 --> 08:32.700
end of the MAC address is with an a here and then ends with a b ends with a c

160
08:32.700 --> 08:33.780
and ends with a d.

161
08:33.780 --> 08:39.290
So we could provide our virtual MAC address from one of those four. And that

162
08:39.290 --> 08:40.500
would determine

163
08:40.500 --> 08:45.560
which forwarder we're going to end up forwarding to. So once again, this brings

164
08:45.560 --> 08:46.860
us to a conversation

165
08:46.860 --> 08:51.980
around the methods for load balancing, so load balancing methods here, the

166
08:51.980 --> 08:53.420
first of which is simply

167
08:53.420 --> 08:59.540
round robin. Round robin means that we're going to assign everything fairly. We

168
08:59.540 --> 09:00.700
're just going to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

168
08:59.540 --> 09:00.700
're just going to

169
09:00.700 --> 09:07.060
rotate it's sort of a rotation or I'll just say taking turns concept. And so I

170
09:07.060 --> 09:09.340
'm going to respond

171
09:09.340 --> 09:15.360
to these in order. So if I have four different hosts that show up, I'm going to

172
09:15.360 --> 09:16.700
make sure that my

173
09:16.700 --> 09:21.510
response here tells the first host that, hey, your virtual MAC address is the a

174
09:21.510 --> 09:23.260
MAC address, your

175
09:23.260 --> 09:27.380
virtual MAC addresses, b, your virtual MAC addresses, c, your virtual MAC

176
09:27.380 --> 09:29.100
address is the. So all four of

177
09:29.100 --> 09:33.990
these hosts have a different active virtual forwarder virtual MAC address. So
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

177
09:29.100 --> 09:33.990
these hosts have a different active virtual forwarder virtual MAC address. So

178
09:33.990 --> 09:35.180
from a layer two

179
09:35.180 --> 09:40.070
perspective, when this device here sends a packet to its default gateway, the

180
09:40.070 --> 09:40.940
destination MAC

181
09:40.940 --> 09:46.430
addresses MAC B and it's going to land on this a VF same thing with c and d and

182
09:46.430 --> 09:47.420
a for that matter,

183
09:47.420 --> 09:51.610
they're all going to land on their appropriate a VF, thanks to standard layer

184
09:51.610 --> 09:52.700
two forwarding.

185
09:52.700 --> 09:58.380
And so again, we'd be taking turns from the AVG's perspective, whether just

186
09:58.380 --> 09:59.660
kind of keep rotating

187
09:59.660 --> 10:06.160
and handing out a B CD, a B CD, and that would result in very fair distribution
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

187
09:59.660 --> 10:06.160
and handing out a B CD, a B CD, and that would result in very fair distribution

188
10:06.160 --> 10:07.500
from a number of

189
10:07.500 --> 10:14.160
endpoints perspective. Now we can also use a weighted method. The weighted

190
10:14.160 --> 10:16.380
method recognizes the

191
10:16.380 --> 10:20.950
possibility that maybe this device over here on the right is a very high

192
10:20.950 --> 10:22.380
performance device.

193
10:22.380 --> 10:30.300
So we might want more traffic to go to it. So maybe we want 10%, 10%, 10% to go
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

193
10:22.380 --> 10:30.300
So we might want more traffic to go to it. So maybe we want 10%, 10%, 10% to go

194
10:30.300 --> 10:31.420
to the first three

195
10:31.420 --> 10:36.410
and then 70% to go to the last one. Well, in that case, we could use the

196
10:36.410 --> 10:37.420
weighted configuration

197
10:37.420 --> 10:42.740
and we assign a weight value to each one of these devices, the weight value

198
10:42.740 --> 10:44.540
ranges from 1 to 254,

199
10:44.540 --> 10:49.710
and then those numbers are compared to establish the percentage that each of

200
10:49.710 --> 10:51.260
the gateways gets.

201
10:51.260 --> 10:55.260
And lastly, we can use this option called hostdependent.

202
10:55.260 --> 11:02.940
Hostdependent is actually going to be based on the host MAC address.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

202
10:55.260 --> 11:02.940
Hostdependent is actually going to be based on the host MAC address.

203
11:04.620 --> 11:09.500
We're going to look at the host MAC address and based on that, determine which

204
11:09.500 --> 11:11.580
AVF we hand the host.

205
11:11.580 --> 11:17.580
The nice thing about this is it's consistent for the endpoints or the hosts.

206
11:17.580 --> 11:22.620
So if they go offline and then they come back online or just they need to re-ar

207
11:22.620 --> 11:22.860
pe,

208
11:22.860 --> 11:26.300
every time they re-arpe, they'll get the same virtual MAC address. Whereas with

209
11:26.300 --> 11:27.580
these other two methods,

210
11:27.580 --> 11:32.050
it's going to depend on the AVG and how it's handing things out so that when a
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

210
11:27.580 --> 11:32.050
it's going to depend on the AVG and how it's handing things out so that when a

211
11:32.050 --> 11:33.100
re-arpe occurs,

212
11:33.100 --> 11:37.760
I might get a new active virtual forerator. And so those are our three

213
11:37.760 --> 11:39.420
different methods,

214
11:39.420 --> 11:42.950
and we just need to make sure that we're thinking through how exactly we want

215
11:42.950 --> 11:43.020
to

216
11:43.020 --> 11:48.580
load-balance our traffic in this GLBP environment. Now lastly, we need to pay

217
11:48.580 --> 11:49.980
attention to the addresses

218
11:49.980 --> 11:54.650
that we're going to use for GLBP, starting with the multi-cast address. The

219
11:54.650 --> 11:56.220
multi-cast address we're

220
11:56.220 --> 12:02.450
going to use is indeed that Cisco-owned multi-cast address that we use for HSRP
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

220
11:56.220 --> 12:02.450
going to use is indeed that Cisco-owned multi-cast address that we use for HSRP

221
12:02.450 --> 12:06.220
version 2, which is 224.0.0.102.

222
12:06.220 --> 12:11.040
So long as we're not using GLBP and HSRP version 2 on the same network, which

223
12:11.040 --> 12:12.300
is probably not going to be

224
12:12.300 --> 12:16.430
the case very often, then we'll be fine. And even if we happen to run both of

225
12:16.430 --> 12:17.820
them at the same time,

226
12:17.820 --> 12:20.950
it just means we're not efficiently forwarding our traffic. It doesn't mean

227
12:20.950 --> 12:22.380
that they can't both run

228
12:22.380 --> 12:26.970
on top of each other if needed. So next we have to pay attention to the virtual

229
12:26.970 --> 12:27.660
MAC address,

230
12:27.660 --> 12:31.180
and the virtual MAC address is going to look a little bit different compared to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

230
12:27.660 --> 12:31.180
and the virtual MAC address is going to look a little bit different compared to

231
12:31.180 --> 12:33.020
HSRP and VRRP,

232
12:33.020 --> 12:40.700
not just numerically speaking, but structure-wise. So we have 007.b40, and then

233
12:40.700 --> 12:41.180
we're going to find

234
12:41.180 --> 12:47.410
that we have two different variables at play here. We have x, x, x, and then y,

235
12:47.410 --> 12:50.620
y. So y, y, do we have two

236
12:50.620 --> 12:56.180
different variables? Well, like with HSRP version 2, we're going to provide a

237
12:56.180 --> 12:58.140
bunch of group IDs here.

238
12:58.140 --> 13:03.070
Here's the problem with this. Even though it looks like we have 12 bits here, 3
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

238
12:58.140 --> 13:03.070
Here's the problem with this. Even though it looks like we have 12 bits here, 3

239
13:03.070 --> 13:03.660
hex characters

240
13:03.660 --> 13:10.330
as 12 bits, we're actually only given 10 of those bits. So that gives us 1,024

241
13:10.330 --> 13:11.340
group IDs.

242
13:14.460 --> 13:20.210
Kind of an interesting restriction, but that is how the bits have been assigned

243
13:20.210 --> 13:21.900
. Lastly,

244
13:21.900 --> 13:30.140
this y, y, this is going to be our AVF identifier. So when an AVF is assigned
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

244
13:21.900 --> 13:30.140
this y, y, this is going to be our AVF identifier. So when an AVF is assigned

245
13:30.140 --> 13:32.060
and mapped to the AVG,

246
13:32.060 --> 13:37.070
it's going to get an identifier assigned to it, and that is going to go in here

247
13:37.070 --> 13:37.660
, which feels a

248
13:37.660 --> 13:42.640
little excessive to give us 256 different values for that. But we do have two

249
13:42.640 --> 13:43.740
full hex characters to

250
13:43.740 --> 13:50.190
represent the active virtual forerator identifier. So this is again how GLBP

251
13:50.190 --> 13:52.700
operates. We have one AVG

252
13:52.700 --> 13:56.640
that performs all control plane operations, including the load balancing, and

253
13:56.640 --> 13:57.580
the way we do the load

254
13:57.580 --> 14:02.140
balancing is through ARP responses. I've got the many different load balancing
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

254
13:57.580 --> 14:02.140
balancing is through ARP responses. I've got the many different load balancing

255
14:02.140 --> 14:03.020
methods here,

256
14:03.020 --> 14:08.090
and then from a data plane perspective, the individual endpoints are going to

257
14:08.090 --> 14:09.020
receive those virtual

258
14:09.020 --> 14:13.420
MAC addresses, and so different endpoints will have different VMAX, and those

259
14:13.420 --> 14:14.460
different VMAX from a

260
14:14.460 --> 14:18.700
layer 2 perspective will ensure that I'm landing on a different active virtual

261
14:18.700 --> 14:19.820
forerator, which does

262
14:19.820 --> 14:25.590
allow all of my AVFs to be forwarding the traffic in a redundant fashion, but

263
14:25.590 --> 14:27.100
also in a load balancing

264
14:27.100 --> 14:27.660
fashion.