We have a lot of options for first-hop redundancy protocols.
We can deploy for example Cisco's hot standby router protocol or HSRP as one of
these options.
Now Cisco was the first to really create one of these protocols in HSRP and so
they were
very early on they had HSRP version 1 and later on they released HSRP version 2
.
These days we should absolutely be running version 2 and we'll talk about the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
These days we should absolutely be running version 2 and we'll talk about the
differences
here but since Cisco actually still supports HSRP version 1 in fact it's the
default configuration
if you add HSRP onto your device.
So we need to be careful as far as explicitly enabling HSRP version 2 in order
to add
HSRP to our configurations.
Now the idea of HSRP is to create groups that are going to operate per subnet WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now the idea of HSRP is to create groups that are going to operate per subnet
and ultimately
per VLAN.
So I might have for example a pair of multilayer switches, we've got layer 2
connectivity
between them and then I've got three sets of SVIs.
So let's say I've got SVIs for VLANs 10, 20 and 30 on the left and then SVIs
for 10,
20 and 30 on the right.
I'd say left or right on that either way, 10, 20, 30 on the left, 10, 20, 30 on
the right. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the right.
So what we're going to do is we're going to create groups.
So I might create group 10 and group 10 is going to be for our SVIs in VLAN 10
and then
I can create groups 20 and 30 to do the same thing for the SVIs in VLANs 20 and
30.
Please make sure that as we send HSRP messaging back and forth that we're not
failing over
to, I don't know, let's say that the SVI for VLAN 10 goes down on the right. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to, I don't know, let's say that the SVI for VLAN 10 goes down on the right.
We wouldn't want to fail over, this is the active note over here.
We might want to fail over for VLAN 10 but we don't also want to fail over for
VLANs 20
and 30.
That wouldn't be conducive.
We would stay online over here and we want to have as few failovers as possible
in order
to promote stability in the network.
So the groups help us to identify which ones or which gateways are paired up WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So the groups help us to identify which ones or which gateways are paired up
with one
another so that we can make sure that we're performing our redundancy checks
correctly
and failing over the correct SVIs.
Now we are going to elect an active note so let's say the note on the left is
the active
that makes the note on the right the standby and this is on a per group basis
meaning that
we could actually mix and match and by all rights we can and should mix and
match.
So we might actually have active and standby not by note here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we might actually have active and standby not by note here.
We might say that I'm active for VLAN 10 on the left.
I'm active for VLAN 20 on the right and then back to the left for VLAN 30
something along
those lines and importantly HSRP is going to use those exact terms for our two
nodes.
We're going to have active nodes and we're going to have standby nodes and
these are the primary
two roles.
But we do have a third role and that third role is going to be listen mode. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But we do have a third role and that third role is going to be listen mode.
Meaning that I might actually have a third device out here that has these three
SVIs and
it could all be part of the same network and at that point I'm going to be just
sitting
there listening to messages.
I am neither the active nor the standby so just to put those standby labels up
here.
I'm neither the active nor the standby so I am just in listen mode for all of
these groups.
And if the active ever goes down then the standby will transition to active and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And if the active ever goes down then the standby will transition to active and
the listen will
transition over to standby.
If I have multiple listens then ultimately the one that has the best priority
value is
going to make the conversion up to standby.
So we can have as many devices in the group as we want but all of them are
going to be in
listen mode if they're not voted as active or standby.
And so that brings us to the question of well how are we choosing these roles. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so that brings us to the question of well how are we choosing these roles.
Well the way we do this is with a priority value and with the priority value on
this one
it's going to be that the highest priority wins.
Now I know we learn a lot of priority values we learn about OSPF priorities, Hs
rp priorities,
spanning tree root priorities, all of these different priority values.
Sometimes the highest one wins and sometimes the lowest one wins.
So how do I keep track of this?
Well I do have a helpful way of thinking about it that can help us to remember WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well I do have a helpful way of thinking about it that can help us to remember
but there
are a couple of exceptions to it so I want to lay that caveat first.
But the generally speaking if a protocol is layer 3 focused like OSPF, the IGRP
, Hsrp,
if it's layer 3 focused the higher number usually wins, if it's layer 2 focused
talking
about spanning tree protocol, ether channels, LECP, those kinds of things then
usually the
lowest priority value is going to win.
So basically layer 3, higher wins, layer 2, lower wins. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So basically layer 3, higher wins, layer 2, lower wins.
And again there might be a couple of exceptions out there but it's a lot easier
to remember
the exceptions and rather than try to remember all of them.
So just kind of keep this in mind moving forward independent of even the FHRP
conversation
although naturally it applies right here.
Now our priority value can be between 0 and 255 we get the full 8 bit range for
that so I
can go to the device that I want on a specific SVI. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
can go to the device that I want on a specific SVI.
Let's say I get on to the VLAN 30 interface here and I can configure it with a
priority of
255 as high as I want to go there.
And for that matter by the way what happens if we have the same priority value?
Well the tie breaker is going to be the highest IP address.
So in theory we don't have duplicate IP addresses on the network that would be
pretty bad.
So somebody is going to have to win the tie breaker as far as having a higher WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So somebody is going to have to win the tie breaker as far as having a higher
IP address.
So from here we can get into other configurations and certainly a lot of this
involves configurations,
the group ID, the priority value and keep in mind that at this point in the
blue print
we're really focusing more on general knowledge, black boarding here.
We're just kind of talking about all the different components of our FHRP's
later on when we
get into the configuration section we're going to be putting our hands on the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
get into the configuration section we're going to be putting our hands on the
CLI and configuring
HSRP and all these other FHRP's.
So for now we're going to talk about some of the configuration parameters and
then later
on we're going to refresh our knowledge on some of this as we actually
configure devices
to perform fail over using HSRP.
But as far as some of the other configuration parameters go and again we do
have a few that
we've already talked about here but we do have the ability to change the timers WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we've already talked about here but we do have the ability to change the timers
.
The timers are how we track whether a device has gone down or not.
So generally speaking we have a or by default I suppose we have a three seconds
hello timer and we have a 10 second hold timer.
So just like with a lot of other protocols if you've got two devices sending
messages
to one another we're going to send the hello message or we're going to send a
message
every hello timer.
So we're sending it every three seconds three seconds later I'll send another WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we're sending it every three seconds three seconds later I'll send another
one three
seconds later I'll send another one.
And if I don't receive one for the hold timer so now it's gone 10 seconds by
default
again without me receiving one from the other side I'm going to assume the
other side is down.
Now yes this does mean that I have to wait 10 full seconds to decide that the
active has
gone down and so we might want to go a little bit faster than that and so we do
have access
to millisecond timers but only with HSRP version two. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to millisecond timers but only with HSRP version two.
So one reason why we want to go with HSRP version two is to make sure that we
can go with
smaller timers and in more advanced configurations as well we might actually
end up deploying
bidirectional forwarding detection or BFD which is a way a very lightweight
mechanism that
allows us to very quickly detect failures and this can be placed over routing
protocols
and it can actually be placed over HSRP as well at which point we could use the
default
timers and rely on BFD to detect the faster failover. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
timers and rely on BFD to detect the faster failover.
So keep that in mind as well that we'll see BFD showing up throughout the
course but either
way we can still just configure HSRP with millisecond timers detect it very
quickly using
HSRP mechanisms as far as other configurations we have preemption and by the
way preemption
is disabled by default that is important for us to know we need to make sure
that if we
do want preemption enabled like we described in the previous video that we have WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
do want preemption enabled like we described in the previous video that we have
to enable
it and so that's a consideration there and we also have authentication
authentication is
important because the winner of HSRP negotiations is declared the default
gateway and we want
to prevent our threat actors from performing man in the middle attacks.
So one way they could do a man in the middle attack is to send bad HSRP
messages with a very WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
messages with a very
high priority say my priority is 255 and hope I become the default gateway.
If I become the default gateway then everybody is going to send their messages
to me and then
I can send them out and that's the man in the middle attack we want to prevent.
How do we prevent it though?
Well the way we do it is by authenticating our messages HSRP allows us to
configure a
password that is hash and then we can validate that the person claiming to be a
high priority WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
high priority
HSRP node actually belongs on the network.