So, one thing that we may have noticed is that HsRP and VRRP, these are only
going to support
one active node. Whether that's HsRP active or VRRP master, but we're only
forwarding
out one device. So, if I have two devices and there are just routers with layer
three
interfaces, then all of my traffic is going to go up this way towards the
active node,
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
assuming that's the active node on the left there, leaving this node on the
right as being
relatively idle. Now, part of this can be resolved by leveraging HsRP and VRRP
with
layer three switches. Because, as we mentioned before, we might have a slew of
SVIs. We could
have dozens of these SVIs in here. We're connecting our devices via layer two.
And so,
we recognize that these two SVIs are going to be part of one group. And so, let
's say
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
the active is on the left for this particular set of SVIs. But then, we pair up
these
SVIs. So, this can be a completely different VLAN and the active for that VLANs
on the
left. And we alternate back and forth and we can divide up our VLANs in the
same way we
like to do with spanning tree protocol routes. And so, this does give us some
amount of
load balancing. But we still can't have more than one active device at a time
using these
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
two protocols. And this is going to lead us to a conversation around Cisco's
gateway load
balancing protocol or GLBP. GLBP was designed to give us multiple active
forwarders, referring
to our gateways. So, how exactly does this work? Well, GLBP is just going to
allow us to
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
have up to four different devices that can serve as gateways. So, all of these
would have the same
SVI. And all of them are capable of forwarding. And so, I want to load balance
the traffic
as I get my client traffic in here. So, this is my set of endpoints. And we're
going to use
some form of load balancing mechanism to direct these endpoints to these four
different
devices, all sharing one virtual IP address. We have one virtual IP address. We
're forwarding
to four different devices. And those are now all active in this environment. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to four different devices. And those are now all active in this environment.
Now, first
glance, GLBP feels like, oh, this is the superior version of HSRP. Or we might
as well not use HSRP
and VRRP anymore. The reality is that GLBP never really took off. It does have
the ability
to load balance and it supports up to four active forwarders at once. And that
's great.
But it was a much more complex configuration. And furthermore, what we found in
most of
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
our environments is we didn't need more than two different gateways. So, we'd
have a pair of
layer three switches serving as the gateways using our SVIs and our VLAN
interfaces. And so,
this form of load balancing up here, just splitting the VLANs between the two,
was a whole
lot simpler for most network engineers to deploy. And for that matter, troubles
hoot when
there are issues relative to deploying a more complex protocol like GLBP. In
fact, these
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
days, Cisco's Nexus platform, which is a data center only application or switch
, we should
only be deploying XSWitches into the data center. But those switches don't even
support GLBP,
even though they're Cisco switches. And this is a Cisco protocol. So, I don't
want to take
the wind out of our sales here. I mean, GLBP is something we should study and
be able to
configure. But from a real world perspective, I wouldn't expect to see a whole
lot of GLBP
out there and I don't want our takeaway out of this conversation to be, oh, I'm
going to
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
go replace my HSRP environment with GLBP because we might not get a whole lot
of benefit
from it. And we might be creating more complexity and a worse ability to
support our network
in the event of having problems. So, one thing that is worth pointing out, I've
already
mentioned it, but this is a Cisco proprietary protocol. This is not industry
standard.
This was created by Cisco. Somebody thought they had a great idea and by all
right, it is.
It's a really neat idea, especially when we break down how it works. It's
really impressive, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
really impressive,
but it's something that didn't really take off in our industry. Now, when we
talk about
GLBP roles, we're going to find that we need new roles. We don't use active and
standby
or master and backup here. Instead, we're going to have two new roles. We're
going to have
the active virtual gateway, which is abbreviated as the AVG. And importantly,
we're going to
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
have one of these. And then we're also going to have the role of active virtual
forwarder.
And that would be abbreviated as AVF. And we can have many AVFs, including by
the way,
the AVG. When we break this down from a high level, the AVG is going to be
responsible for
managing GLBP from a control plane perspective. So we need one device to sort
of be managing
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
what's happening here. Meanwhile, the AVFs, these are all of the gateways that
are capable
of performing data forwarding as the name implies. So in our case down here, we
might have the
AVG all the way on the left, but all of these devices are going to be AVFs,
including the
AVG. It's going to hold both of those roles. Now, we might be looking at this
wondering,
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
what is this load balancing mechanism? How do we make it so that some endpoints
use this
device on the left, some endpoints use this device on the right? What exactly
are we doing
there? Well, the way we do this is actually fairly simple. We apply a different
virtual MAC address
per AVF. Now remember, we are still sharing a virtual IP address. So this gets
shared among
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
all of our devices. And that makes sense because all of our endpoints need to
be configured
with a single default gateway. We're not load balancing by giving them
different IP addresses.
We could do that without GLBP. We just have to deal with failures, which is not
so good. But
GLBP allows us to share a virtual IP address. And yet, we're going to have,
again, maybe
four, I'm going to say many here, I suppose, but up to four different AVFs each
with their
own virtual MAC address. Furthermore, because the AVG is responsible for the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
own virtual MAC address. Furthermore, because the AVG is responsible for the
control mechanisms,
it's going to perform all of the ARP responses. And it's going to perform the
load balancing
by deciding which virtual MAC address to hand to each endpoint. Now, let's go
ahead and
walk through an example here. So let's say that we have a device come online
and we have
this GLBP configured, the virtual IP addresses dot 254. And so we have our
gateway configured
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
is whatever the subnet is dot 254. And I need to know what the MAC address is.
How do I do
that? Well, of course, I'm going to send an ARP request out into the network.
Now, we just
said that the AVG is going to perform all ARP responses. An ARP is a broadcast
packet. And
so that means that all of these devices are going to receive the ARP response
or the ARP
request rather for dot 254. So they all receive the request, but only the AVG
sends the response. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
sends the response.
And so the question is what is the virtual MAC address that we're responding
with? Well,
the AVG can use one of its load balancing methods. And we'll talk about those
in a moment
to decide which one of these AVS AVFs to provide from a VMAQ perspective. So
let's say we have
our four different VMAQs. And we will just say that they end in dot a, I guess
not dot a, but the
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
end of the MAC address is with an a here and then ends with a b ends with a c
and ends with a d.
So we could provide our virtual MAC address from one of those four. And that
would determine
which forwarder we're going to end up forwarding to. So once again, this brings
us to a conversation
around the methods for load balancing, so load balancing methods here, the
first of which is simply
round robin. Round robin means that we're going to assign everything fairly. We
're just going to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
're just going to
rotate it's sort of a rotation or I'll just say taking turns concept. And so I
'm going to respond
to these in order. So if I have four different hosts that show up, I'm going to
make sure that my
response here tells the first host that, hey, your virtual MAC address is the a
MAC address, your
virtual MAC addresses, b, your virtual MAC addresses, c, your virtual MAC
address is the. So all four of
these hosts have a different active virtual forwarder virtual MAC address. So WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
these hosts have a different active virtual forwarder virtual MAC address. So
from a layer two
perspective, when this device here sends a packet to its default gateway, the
destination MAC
addresses MAC B and it's going to land on this a VF same thing with c and d and
a for that matter,
they're all going to land on their appropriate a VF, thanks to standard layer
two forwarding.
And so again, we'd be taking turns from the AVG's perspective, whether just
kind of keep rotating
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
and handing out a B CD, a B CD, and that would result in very fair distribution
from a number of
endpoints perspective. Now we can also use a weighted method. The weighted
method recognizes the
possibility that maybe this device over here on the right is a very high
performance device.
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
So we might want more traffic to go to it. So maybe we want 10%, 10%, 10% to go
to the first three
and then 70% to go to the last one. Well, in that case, we could use the
weighted configuration
and we assign a weight value to each one of these devices, the weight value
ranges from 1 to 254,
and then those numbers are compared to establish the percentage that each of
the gateways gets.
And lastly, we can use this option called hostdependent.
Hostdependent is actually going to be based on the host MAC address. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Hostdependent is actually going to be based on the host MAC address.
We're going to look at the host MAC address and based on that, determine which
AVF we hand the host.
The nice thing about this is it's consistent for the endpoints or the hosts.
So if they go offline and then they come back online or just they need to re-ar
pe,
every time they re-arpe, they'll get the same virtual MAC address. Whereas with
these other two methods,
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
it's going to depend on the AVG and how it's handing things out so that when a
re-arpe occurs,
I might get a new active virtual forerator. And so those are our three
different methods,
and we just need to make sure that we're thinking through how exactly we want
to
load-balance our traffic in this GLBP environment. Now lastly, we need to pay
attention to the addresses
that we're going to use for GLBP, starting with the multi-cast address. The
multi-cast address we're
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
going to use is indeed that Cisco-owned multi-cast address that we use for HSRP
version 2, which is 224.0.0.102.
So long as we're not using GLBP and HSRP version 2 on the same network, which
is probably not going to be
the case very often, then we'll be fine. And even if we happen to run both of
them at the same time,
it just means we're not efficiently forwarding our traffic. It doesn't mean
that they can't both run
on top of each other if needed. So next we have to pay attention to the virtual
MAC address,
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
and the virtual MAC address is going to look a little bit different compared to
HSRP and VRRP,
not just numerically speaking, but structure-wise. So we have 007.b40, and then
we're going to find
that we have two different variables at play here. We have x, x, x, and then y,
y. So y, y, do we have two
different variables? Well, like with HSRP version 2, we're going to provide a
bunch of group IDs here.
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
Here's the problem with this. Even though it looks like we have 12 bits here, 3
hex characters
as 12 bits, we're actually only given 10 of those bits. So that gives us 1,024
group IDs.
Kind of an interesting restriction, but that is how the bits have been assigned
. Lastly,
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
this y, y, this is going to be our AVF identifier. So when an AVF is assigned
and mapped to the AVG,
it's going to get an identifier assigned to it, and that is going to go in here
, which feels a
little excessive to give us 256 different values for that. But we do have two
full hex characters to
represent the active virtual forerator identifier. So this is again how GLBP
operates. We have one AVG
that performs all control plane operations, including the load balancing, and
the way we do the load
balancing is through ARP responses. I've got the many different load balancing WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
balancing is through ARP responses. I've got the many different load balancing
methods here,
and then from a data plane perspective, the individual endpoints are going to
receive those virtual
MAC addresses, and so different endpoints will have different VMAX, and those
different VMAX from a
layer 2 perspective will ensure that I'm landing on a different active virtual
forerator, which does
allow all of my AVFs to be forwarding the traffic in a redundant fashion, but
also in a load balancing
fashion.