In this video, we're going to cover yet another first hop residency protocol
with its configuration
and verification. In this time, we're going to use GLBP. That's the gateway,
load balancing protocol.
And the two major roles, this is based on priority, is we're going to have the
AVG. And the AVG has
a few responsibilities, including it's going to respond to our requests for
clients that are asking,
"Hey, what is the layer to address for our default gateway?" And regarding
their response, it gives.
If we have three routers, for example, in our GLBP group, it could go ahead and
hand out, for example,
1010 and then 1011 and 1012. If those were the virtualized MAC addresses that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
1010 and then 1011 and 1012. If those were the virtualized MAC addresses that
each of the
routers were using, and where do they get those virtual MAC addresses? The
device acting as the AVG
also assigned the AVFs, as the active virtual forwarders, their respective
virtual MAC addresses.
So the AVG is the brains behind the operation that's assigning out these
virtual MAC addresses to the,
in this case, three routers that would be participating on that segment. Let me
go ahead and draw another
router here. We'll put router 9, connect it in. And then whichever device is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
router here. We'll put router 9, connect it in. And then whichever device is
acting as the AVG
is going to be getting the ARP requests for the virtualized IP address, and
responding back to the
client with one, in this case, one of the three MAC addresses to provide load
balancing. So a third
of the clients could be using one physical gateway, another, a third could be
using a different
physical gateway, and yet a third group of computers could be using a third
virtual gateway. And it's
all due to which MAC address they got back from the AVG regarding their query.
How do I reach
.99? What's the layer to address for .99? Also, gateway load balancing protocol WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
.99? What's the layer to address for .99? Also, gateway load balancing protocol
has some fault
tolerance mechanisms for the AVG itself. So if the AVG goes away, for example,
let's say it's R1,
that's the AVG, and it goes away, and the other members in the group realize,
hey, the AVG is gone,
they'll have a new election, and they'll point a new one. Or in the event, we
have one of our routers.
It has the virtual MAC address, 1011, and it goes away, that MAC address,
because it's already in the
cache of our PCs. If that's already being used, another member in the group
will be given the
responsibility of forwarding based on that MAC address. So the goal is that no WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
responsibility of forwarding based on that MAC address. So the goal is that no
matter what happens to
just a single router or a portion of our routers, if we have at least one
router standing with gateway
load balancing protocol, it can still provide that fault tolerance as the
default gateway function.
So as far as our game plan for gateway load balancing protocol, let's do the
following. Let's configure
R2 as the AVG. In the way we can do that, it's just simply configure it first.
And if we want to also
give it a higher priority, that would also confirm it keeps it once the other
routers are in place. So WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
routers are in place. So
on R2, we'll make it the AVG by giving a priority of 105. Let's also set it pre
-empt. And then on
R1, we'll give it a priority of 99, and we'll also enable pre-empt there. Now,
even though R2 is
going to be the active virtual gateway and R1 is not, these two routers are
also going to be acting
as an AVF, an active virtual forwarder. And it's part of that this might have a
virtual MAC address of
1010 and down here a virtual MAC address of 1011. And as the active virtual
gateway sees our request
coming in, trying to resolve that .99 address and find out what the layer 2 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
coming in, trying to resolve that .99 address and find out what the layer 2
address is for it,
the active virtual gateway can respond back with, first of all, like 1010,
which would mean
R2 itself is going to be forwarding that traffic, or I can respond with 1011,
which would mean
that R1 is going to be forwarding the traffic. And it can go ahead and round
robin between the two.
And that's how we can accomplish load balancing with gateway load balancing
protocol and have the
redundancy as well. So if either of the routers fails, the other one will pick
up the slack and keep
on going. So with that in mind, let's go back to the lab environment and let's
configure WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
configure
R2 and R1 for gateway load balancing protocol. So here in the lab environment,
in my notepad document,
just to make it a little bit more convenient for the implementation error, I
have a section for
GLBP. And so on R1, we're going to default interface gig 00, and I then go in
and put its IP
address back on, which is 101201. And then we're going to set up GLPB group
number one. So we're going to
specify the virtual IP address, the priority, and also specify preempt. And
then in R2, very similar
treatment except we're going to go ahead and give it a priority of 105. The IP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
treatment except we're going to go ahead and give it a priority of 105. The IP
address on the
actual interface itself for R2 is going to be 101202. And the priority we're
going to specify for
gateway load balancing protocol is going to be 105. So with that in mind, let
me go ahead and copy
the config here for R1. We'll right-click copy, go to the right router, there's
R1, and we'll paste it
in. And we'll do the same thing for R2. So we'll go ahead and copy the config
here for R2, copy,
and then before we paste it in, I noticed here that we had a state change going
from speak to active.
So R1 is the AVG. So here on R1, if we did a show, GLBP, I'm pressed enter, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So R1 is the AVG. So here on R1, if we did a show, GLBP, I'm pressed enter,
here's showing the
state as active, here's the virtual IP address, preempt is enabled, active is
local, we don't have a
standby set up yet, we have one forwarder, one active virtual forwarder, and
that's R1 itself.
And state is active, and here's the MAC address that it's using for its active
virtual forwarding
function, it's 0, 0, 0, 7, B400, ending in 0, 1, 0, 1. The actual MAC address
is not identical to what
it was with the RRP, however the last four characters happened to be. So this WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it was with the RRP, however the last four characters happened to be. So this
is 0, 1, 0, 1.
So once we configure R2, so I'll go ahead and copy that back into my buffer,
and we'll go to R2,
and we'll paste that in, and we'll give that a moment to settle. Here for
Gateway Load Balancing
Protocol, it went from state speak to active. So here, if we did a show GLBP, I
'm pressed enter,
and then we have another state change here, let me go ahead and do that show GL
BP again.
So here's showing the state as active, here's the virtual IP address, the
active router is local, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the standby is over at 10, 12, 0, 1, our priority is 105, the waiting, and that
's going to impact the
load balancing ratio. The waiting is at 100 by default, the load balancing
mechanism is round
Robin, and the group members are 10, 12, 0, 1, with that corresponding layer to
address on that
real interface, that's R1, and ourselves at 10, 12, 0, 2, with that MAC address
associated with that
interface. So in R2, it's its gig 1/0 interface. And here's showing us there's
two forwarders. So we
have forwarder 1, disappointing this MAC address, and the owner has the MAC WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
have forwarder 1, disappointing this MAC address, and the owner has the MAC
address of the one ending in
0, 0, 8, so that equates to R1, and forwarder 2 is using this virtual MAC
address, 0, 0, 7, B400, 0, 0, 0, 1, 0, 2,
and this is the actual real MAC address on R2 on its gig 1/0 interface. So just
to test this out,
if we had multiple clients here on this network segment, the 10, 12, 0 network,
that were making our
request for .99, the active virtual gateway would be handing out first the MAC
address of 0, 1, 0, 1, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
address of 0, 1, 0, 1,
and then for the next request would be 0, 1, 0, 2, and then it would round
Robin back to 0, 1, 0, 1.
Now to confirm that, what we could do is go to PC12, and here on PC12, let's go
ahead and do a show
ARP, look at the ARP cache, the ARP cache is empty, that's convenient, if it
wasn't, we could do a clear
ARP, and that would remove everything. So here let's go ahead and do a ping to
4.4.4.4, which will
cause PC12 to make an ARP request and let's do a show ARP and press center. So
there's the MAC address
that was given 0, 1, 0, 1. So if we clear the ARP cache, the clear ARP, and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that was given 0, 1, 0, 1. So if we clear the ARP cache, the clear ARP, and
then we did a ping again,
it's going to make an ARP request again for its default gateway address, but
this time,
with the round Robin from the active virtual gateway, it should be handing out
0, 1, 0, 2. We can
verify that with a show ARP, press center, and sure enough, 0, 1, 0, 2. Also if
we looked at the
switch MAC address table, which we should do right now, let's go to switch 1,
and here at the switch,
let's do a show MAC address table, press center. Even as here, we have this MAC
address associated with
gig 0/1, and this MAC address, ending in 0, 1, 0, 2, associated with gig 0/2. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
gig 0/1, and this MAC address, ending in 0, 1, 0, 2, associated with gig 0/2.
So currently the PC,
let's go back to PC12, it's currently using 0, 1, 0, 2. So if we go back to
switch, 0, 1, 0, 2,
is associated with gig 0, 2, which goes out to router 2. So if we were to tell
router 2 on its
interface, let's do that real quick. So if we're going over to R2 on gig 1, 0,
and we shut it down,
R1 would recognize I'm no longer seeing messages over this common Ethernet
segment, and it would
take over responsibility for that MAC address. Because R2 not only is going to
lose its role as the
active virtual gateway, because that interface is shut down, but it'll also WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
active virtual gateway, because that interface is shut down, but it'll also
lose its role as an
active virtual forwarder, because it's no longer reachable. So let's go to R2's
gig 1, 0. So go to R2,
go to configuration mode for interface gig 1/0, and let me confirm we got the
right interface,
yeah gig 1, 0, and let's go into a shutdown. So while that's shutting down, let
's also go back to
PC12. This is a verify that we still have that in our ARP cache. Oh, it's going
to be expiring 3 seconds.
Well, let's go ahead and do a ping to 4444, and let's do a show ARP, and it was WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well, let's go ahead and do a ping to 4444, and let's do a show ARP, and it was
given 0, 1, 0, 1.
So now that R2 is out of the picture, let's go ahead and clear ARP, and let's
ping again,
and let's do a show ARP, and I hit clear ARP by default. So let's go ahead and
let's try that
again, let's do a ping to 4.4.4. Let's do a show ARP, and so now currently has
the MAC address of 0, 1, 0, 2.
Let's go ahead and clear the ARP cache, and then ping again, which will once
again cause us to do an
ARP request in the background, then we'll do a show ARP, and now we have the
MAC address of 0, 1, 0, 1. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
MAC address of 0, 1, 0, 1.
So at the moment, R1 is supporting not only the role of the active virtual
gateway,
responding to ARP requests, but it's also responding for both virtual forward
ers that had been present,
and now that R2 is gone, R1 is carrying all the weight. So if we go to switch 1
, and we do a show MAC
address table here, notice that these two MAC addresses are both associated
with gig 0/1,
that's the port going down to R1, who's currently taking responsibility for
both of those MAC addresses.
And here on R1, if we do a show, GLBP in present, or it is the active virtual WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And here on R1, if we do a show, GLBP in present, or it is the active virtual
gateway,
there are two forwarders, and even though R2 is no longer reachable or
available,
we are doing the forwarding for both. And that's why I right here shows as
forwarder 1,
that this router R1 is active, and for forwarder 2, it's also active. So if we
were to go to R2,
let's go ahead and do a no-shot on the center face, and because preempt is
enabled,
and it has a higher priority, suffer a few moments, we'll do a show GLBP, it
shows there's two forwarders, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
shows there's two forwarders,
and for forwarder 1, the state is listen, that's on this local router, and if
we go down to forwarder 2,
the state is active. Effectively what that means is that router 2, the one we
're currently looking at,
is forwarding for this virtual MAC address right here, and router 1 is forward
ing for this virtual
MAC address right here. And if we went to R1, and in R1, if we did a show GLBP
in present center,
here showing that for forwarder 1, it's active, meaning it's forwarding based
on that MAC address,
0101, and forwarder 2, R1 is acting as a state of listen. That means R2 is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
0101, and forwarder 2, R1 is acting as a state of listen. That means R2 is
actually doing the forwarding
for that second forwarder group with the MAC of 0102. And we can verify that
also on the switch by
going to the switch, and how the switch doing a show MAC address table, and
indeed 0101 goes out
to the port where R1 is, and 0102 goes out to the port where R2 is. And in the
event that we had a
failure on R1, so let's go to R1, did a config T, interface gig, 0/0, we'll do
a shutdown,
so now that it's down, if we go over to R2, or a moment ago, it was doing a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
so now that it's down, if we go over to R2, or a moment ago, it was doing a
listen state for forwarder
1 and being active from forwarder 2, now it should be active for both forward
ers, because R1 is no
longer part of the picture. So we'll do a show GLBP in present center, you go
down, and sure enough,
we are active for the first MAC address here of 0101, and we're also active for
the second MAC address
of 0102. So we're here to go back to PC12, and it's going to show ARP, and it's
going to do a ping
to 4444, now it's R2 doing all the work. So we do a show ARP, and it's going to
do a clear ARP, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and we'll do a ping again, and then once that's done, we'll look at the ARP
cache, and we should have
0102, and all of this work is now being done by R2. And so we should see those
MAC addresses
ending in 0101 and 0102, from the switch perspective, both going out to gig 02
where R2 is. So if we get
the upper key, do a show MAC address table, sure enough there's those two MAC
addresses right there,
being supported now fully by R2. And if we brought our one back by doing a no
shutdown,
and giving it just a few moments, so let's go ahead and generate some traffic
here, let's go ahead, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
here, let's go ahead,
and from PC12, we'll do a, let's do a clear ARP, and they'll do a ping to 4444,
and a show ARP,
and a clear ARP, and another ping that should have round robbed into the second
MAC address of 0102,
we'll do a show ARP, it's sure did, and then if you dig a look at the switch,
here's switch number 1,
and we hit the upper arrow key in press center, now it has the 0101 going over
to the port that's
connecting R1 to the network, and if we look at 0102, the switch believes that
's reachable out of gig 02,
which goes over to R2. So in this video, we've taken a look at the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
which goes over to R2. So in this video, we've taken a look at the
configuration and verification
of gateway load balancing protocol, and in the next video, I'd like to give you
an opportunity to
get some hands-on practice with all three of these first hop redundancy
protocols.