Now, there's one other part that we need to talk about, which goes a little bit
deeper
into how FHRP's work.
And that is how we handle the Layer 2 Failover aspect of FHRP's.
The Layer 3 Failover feels fairly straightforward.
I have two devices.
They are sharing this virtual IP address.
Let's say it's that.254 that we're sharing.
.252 on the left.
.253 on the right.
And we know that our endpoints down here are going to have that default gateway WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we know that our endpoints down here are going to have that default gateway
of .254.
We want to point them to the virtual IP address.
So that's the Layer 3 aspect of it.
And again, we know that if this device goes down, then this device takes over
or vice-versa,
whichever one is active, it doesn't matter, which one we decide should be
active, but
we do have control over that.
So we say that the one on the left is the active node.
And if it fails, then the node on the right will answer to the .254.
But now we need to think about this Layer 2 Failover concept. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But now we need to think about this Layer 2 Failover concept.
So think about this.
We have an upstream switch from this device.
And then we've got a little bit of a Layer 2 network here.
So we've got a switch coming over here.
That comes up to the router on the left.
We've got a switch over here.
Going to the router on the right.
And on steady state operation, everything is working just fine.
But then what happens when we do have a failover?
So now let's say we have this failover and we're now trying to run off of the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So now let's say we have this failover and we're now trying to run off of the
router on
the right.
In this scenario, this entire network is going to go down unless we address
Layer 2 Failover.
Because if we think about it, remember, this virtual IP address is also going
to have
a virtual MAC address.
Where does the network think the virtual MAC address lives?
If we look at the cam table for this switch, we're going to point out this
interface to say,
hey, that virtual MAC address lives out this way. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
hey, that virtual MAC address lives out this way.
And for that matter, even this switch on the right is going to for now.
If we've got a host over here trying to get to its gateway, we might send a
packet to
this switch.
And it's going to follow these arrows.
It's going to go down here to this switch and bounce up here to the switch on
the left.
Because the virtual MAC addresses, the virtual MAC address, has been inserted
into the cam
tables of all of these Layer 2 switches.
So we need to update the cam tables as part of this design. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we need to update the cam tables as part of this design.
Because otherwise we're going to failover and this device over here is actually
running
the .254 IP address.
And for that matter, it's running the virtual MAC address, but nobody knows
where it is.
And so how do we update the Layer 2 network to let everybody know that the
virtual MAC address
now lives out this interface and it no longer lives out this interface?
Well the way we do this is with a mechanism known as a gratuitous, which is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well the way we do this is with a mechanism known as a gratuitous, which is
often abbreviated
as a garp, which I think is a really funny acronym.
But the garp is an ARP packet that is sent gratuitously.
Now gratuitous is kind of a funny English word.
It basically means excessive or in this case it's going to mean unrequested.
Because when steady state operation, remember I sent an ARP request and that AR
P request WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
P request
was a broadcast, it eventually landed up here on the router when it was alive
and it sent
that ARP request.
And that ARP request is why we know in all these cam tables where that MAC
address lives.
Because when we do the ARP from this side, we're going to get the ARP response,
everybody
knows where it lives.
So which is perform that flood and learn type of behavior.
Well gratuitous ARP says, "Hey, nobody is asking." WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well gratuitous ARP says, "Hey, nobody is asking."
Nobody asked for this, but I'm going to send an ARP response.
I'm going to make sure that it's broadcast and flooded throughout the
environment.
So I send that ARP or that garp once I fail over.
So I recognize first of all that the active is down, then I decide I am the
active and
next I send a gratuitous ARP out to this switch. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
next I send a gratuitous ARP out to this switch.
Well the cam table on this first switch is immediately going to recognize that
the virtual
MAC address is moved.
I used to think it was out this interface, now I realize it's out this
interface.
So fortunately layer two mechanisms allow us to update the cam table
immediately.
And so now I know that the virtual MAC address is out the correct interface.
And because this gets broadcasted throughout the entire environment, I send it
down to
this switch.
Now it knows in its cam table that the virtual MAC address lives out the
correct interface. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
correct interface.
So fortunately this is nothing we have to configure, but it is an important
mechanism,
an important part of the FHRP process that a gratuitous ARP ends up getting
sent out
in order to update the layer two network.
So we don't just rely on layer three being updating or being updated and yet
the layer two
network is behind.
[BLANK_AUDIO]