Alright, here we go again.
We're going to jump back into a quiz and review some of the topics, especially
around FHRP's.
Once again, hit the pause button as needed in order to make sure you can answer
these
questions yourselves.
So we start by looking at the multi-cast addresses.
Identify the FHRP that uses each of the following multi-cast addresses.
So we may recall that HSRP version 1 came out and Cisco didn't have a dedicated
multi-cast
address for it. So it uses this .2 which even today is used to multi-cast to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
address for it. So it uses this .2 which even today is used to multi-cast to
all routers.
So any layer 3 device will receive this. Not really ideal.
When VRRP came out, they had 224.0.0.18 reserved for them.
And so again, VRRP is the industry standard FHRP that can be used.
Version 2 and Version 3 both use the same address, keeping in mind that Version
3 has an IPv6
address equivalent, which turns this into hex of 12. So don't forget that. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
address equivalent, which turns this into hex of 12. So don't forget that.
Now lastly, this .102 was created, or maybe I should say reserved by Cisco, for
HSRP version
2 and also GLBP. So they double dipped here. They said, you know, very rarely
will we see
both of these in the same broadcast domain. And so let's just use the same
multi-cast
address. Again, we can use both of these in the same broadcast domain.
It's just the GLBP nodes will be receiving HSRP version 2 messages and vice
versa. And
they'll drop it. It's just not as efficient. So no real need for each one to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
they'll drop it. It's just not as efficient. So no real need for each one to
get its own
multi-cast address.
All right, you knew it was coming. Here we go. Can we match these virtual MAC
addresses
up to each of the FHRP's? And that's what this question's asking. So hit the
pause button
and make sure you can go through this exercise.
So to start with, when we see this, all zeros with the 5E in there, that should
tell us that
we're running VRRP. VRRP has the 0, 0, 0, 0, 5E, 0, 0, 1. And here, this would WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we're running VRRP. VRRP has the 0, 0, 0, 0, 5E, 0, 0, 1. And here, this would
be the group
ID. We only get the two hex characters, which means 8 bits, which means 2 to
the 8th power
of 256 groups. Next, we see 0C. So anytime we see 0C, maybe that C can remind
us of
just that it's for Cisco. It's one of Cisco's HSRP VMAX. We just have to keep
track of the
difference. It might also help that this 07 is much lower than 9F. And so 07, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
difference. It might also help that this 07 is much lower than 9F. And so 07,
we could
think along these lines that it came first. And this is for HSRP version 1 with
the last
two hex characters giving us those 256 groups. And then this last one down here
, 9FF versus
07 AC by the way, but 9FF, this is HSRP version 2. And we actually have all
three of these hex
characters, which means 12 bits and 10 to the 12th power gives us the 4,096 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
characters, which means 12 bits and 10 to the 12th power gives us the 4,096
groups. Pretty
cool with HSRP version 2 giving us that. Now, lastly, by process of elimination
, we have
GLBP in here. We can recognize that GLBP is sort of an outlier. It's a weird
protocol.
And weirdly, it's the only one that has a non-zero digit here as the, or in the
first
section of our MAC address. Also, keep in mind that we have 10 bits in here.
Yes, there's
12 bits total, but we only get 10 of those for groups. So we get 1,024 groups. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
12 bits total, but we only get 10 of those for groups. So we get 1,024 groups.
And then
this last pairing would define an AVF identifier.
And 3, what mechanism is used following an FHRP failover to update the layer 2
network?
So the answer to this would be the garb as I prioritize drawing out the diagram
here.
But remember, if I've got a network switch here, a network switch over here,
network switches
like this, whatever the topology is, if the active is over here, this is where WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
like this, whatever the topology is, if the active is over here, this is where
the V MAC
lives. And this switch down here thinks the V MAC lives out this way. And so if
this device
goes down, by default, I still think the V MAC lives out this link. And so if I
receive
a packet destined for the gateway, that layer 2 frame will get forwarded to
this switch,
this switch recognizes, well, I used to think the V MAC lived out here. That
link is now
down. And so I just don't have an entry for it. So I'm going to flood it out WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
down. And so I just don't have an entry for it. So I'm going to flood it out
all ports.
Well, that's great. And I'll accept I can't flood it out the port I received it
on. So it's
going to flood it out a bunch of ports. And it's just going to get black hold.
And so we
want to update the layer to network. So as soon as the secondary realizes, hey,
I need
to do a failover. I'm going to activate that virtual IP address. And I'm going
to send
out a gratuitous ARP or a garb that is the ARP nobody asked for. And yet I'm
flooding
it out into the network. So I can see, oh, the V MAC lives out this way now. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it out into the network. So I can see, oh, the V MAC lives out this way now.
And the V MAC
lives out this way now. And everybody now knows where that V MAC lives. And it
will prevent
the black holding of traffic. Very important. And yet under maybe studied or
maybe misunderstood
element of FHRPs, absolutely something we want to be certain we understand as
far as the
process is concerned.
All right, question four. And there are six questions, by the way. So we're
over halfway
there. A network engineer configures GLBP among four gateways deploying group WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
there. A network engineer configures GLBP among four gateways deploying group
84 on VLAN 110.
What V MAC is used by an AVF with an ID of 11 Holy smokes. There is a lot of
information
in here. Remember GLBP defines its virtual MAC address not only on the group ID
, but also
on the AVF identifier. Those last two hex characters are all about the
identifier and for the
AVF and the other 10 bits to find the group ID. The VLAN ID has nothing to do WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
AVF and the other 10 bits to find the group ID. The VLAN ID has nothing to do
with this.
So don't let that distract you as we go down this path. We also need to worry
about hex.
So we need to convert all of these numbers to hex. If we were to convert 84 to
hex,
for example, 80 is 16 times 5. So I'd be a 5 with a remainder of 4. So that's a
hex value
of 54 110, even though we're not going to use it. This is where we might see 6E
, where
we take 16, multiply it by 6, get 96. We have a remainder of 14 and E is hex WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we take 16, multiply it by 6, get 96. We have a remainder of 14 and E is hex
for 14. And
then lastly, 11, don't have to do a whole lot of math on that one. Just
recognize that it
goes from 9 to 10 is a to 11 is b. So that b zero b here. But again, we're not
going to
use 6E. So first of all, we see that the OUI is the same for all of these. That
's good.
We could possibly see this value change down here because if we get a group ID
that's large WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that's large
enough and we need those two bits, remember we kind of divide those four bits
and half,
we get those last two, then we might see that number change to one or two or
something
like that. But either way, again, our group ID here is 54 and hex and the group
ID comes first.
So that would be right here. And then the AVF identifier of 11, which is zero b
, would
go right here. So our answer is going to be b. Don't get distracted by decimal WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
go right here. So our answer is going to be b. Don't get distracted by decimal
values.
Don't get distracted by VLAN identifiers in here. We want to make sure we know
how the
vmix are structured, not just for GLBP, but also for HSRP, both versions and VR
RP as well.
Question five, which FHRP configuration is required in order to use object
tracking? So
we're going to use a series of configurations with a FHRP. But the answer to
this question
is going to be preemption because we don't need authentication and we don't WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is going to be preemption because we don't need authentication and we don't
need millisecond
timers. We do need dynamic priority values. That's how we do it. We use that
decrement command.
But that doesn't require us to use a priority greater than 100. I could use 50
and 90 and we
could perform object tracking just fine. So we don't need to use specific
priority values.
We just need to make sure that relatively I can drop the prior, let's say the
active is 90.
I need to drop that priority value below the secondary. So I drop it to maybe WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I need to drop that priority value below the secondary. So I drop it to maybe
40. I do
a decrement of 50 here when an outage occurs that prompts a failover, even
though the active
node is still alive, there's network degradation that we're trying to take into
account. We decrement
50. I'm at 40 now. So that's all well and good. But if I'm sitting here as the
active at 40
and the secondary sitting here at 50 and preemption is not enabled, nothing's
going to change.
I must have preemption enabled on the secondary so that I can see that I'm now WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I must have preemption enabled on the secondary so that I can see that I'm now
better than
you. And I take the active role, which again does require preemption. Pre
emption is disabled
by default with HSRP. So we need to enable it at that point. If we're using VR
RP, it is enabled
by default. And so we're pretty good there.
All right, last question for this quiz, which mechanism is responsible for
preventing routing
a J-sensee flaps during a chassis supervisor failover? We probably often hear WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
a J-sensee flaps during a chassis supervisor failover? We probably often hear
SSO and NSF
that are usually talked about together almost in one breath as if they do the
same thing,
but they do different things. Staple switchover is going to make sure that when
I have a primary
supervisor and a redundant supervisor that whatever's happening here in my
tables, especially
my routing tables, that this gets actively synchronized, this is staple switch
over, actively
synchronized to the redundant supervisor, which means also that this redundant WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
synchronized to the redundant supervisor, which means also that this redundant
supervisor
is online and ready to failover. So this is as hot of a standby as we can be.
And if this
goes down as soon as we detect that supervisor failed for any reason, I can
immediately come
online and I've got all of the table entries already populated. So that is SSO.
But that's
not what we're asking about here. We're asking about routing a J-sensee flaps.
Because
this device here has a routing a J-sensee with another device. And so remember, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
this device here has a routing a J-sensee with another device. And so remember,
this is going
to be down for some amount of time, that is a clock, representing time. And so
while this is down,
we might have millisecond timers that this device here is expecting to receive
hello messages on.
Well, I haven't failed over yet because maybe it takes me three seconds to
detect that there's
an outage or whatever the situation is. And by default, this device is going to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
an outage or whatever the situation is. And by default, this device is going to
tear down this
a J-sensee because it thinks, right, fully so, on some level that its neighbor
has died. So we want
to keep that a J-sensee online and show some amount of grace to say, "Hey, I
know that I'm not
sending any hello messages, but I am NSF capable and therefore you need to show
me grace while I
try to perform a failover." That is the function of NSF nonstop forwarding. The
idea here is that I can WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
idea here is that I can
maintain my adjacencies and I can continue to forward packets by the way, even
though the control
plane is down, in order to hopefully allow me to continue to switch traffic,
which depending on the
architecture of the chassis will allow me to keep doing while the supervisors
are failing over.