Object tracking is something that we should consider with every single FHRP
deployment.
If we don't look at least at object tracking, we're going to probably run into
situations
where there's a reality that our traffic is either getting black hold or is
getting bumped
around and bounced around in a way that is very inefficient.
So again, the scenario is typically we lose a link like this.
I continue to send traffic up to the active. The question is whether we
actually have a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
actually have a
routed layer 3 relationship this way or not. Because if we do, then at least
the active
can route it and send it out towards the other distribution switch.
But if we don't have a routed relationship, because we're trying to optimize
our layer
3, then it truly can't do anything and it will drop the traffic.
So that's why I always say it's either going to get bounced around or possibly
even dropped.
So what we are wanting to do is recognize that because of a network failure
that isn't
directly this device going down, that we still want to fail over to the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
directly this device going down, that we still want to fail over to the
secondary or
the standby backup. In our case, where it's an HSRP version too, so it would be
the standby
device. So we need to decide what we're going to track. What is our object?
What we have
lots of options here. I can track the line protocol of the link to see if it
goes down. I can
track a route in my own routing table and I can even track reachability by
performing
pings essentially up here. And lastly, I could use Cisco's IPS LA. So let's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
pings essentially up here. And lastly, I could use Cisco's IPS LA. So let's
just say we want
to use the line protocol. And by the way, if you chose something else,
perfectly fine,
it's just recognizing what our options are. So I'm going to say we're going to
track
the line protocol. And from here, we need to make sure we have our
configurations in place.
Well, there's two primary aspects to this. First of all, we do need to make
sure that we
have preemption enabled on our secondary. And ideally, we enable it on the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
have preemption enabled on our secondary. And ideally, we enable it on the
primary as
well, not strictly required because as long as we can fail over one way, we're
usually
in good shape. But naturally, if this link comes online and then this link goes
down while
we're still the second of the primary, we'll have the same problem in reverse.
So it really
should be enabled on both sides. Next, that's number one is preemption. Number
two is our
priority design. So we're going to want to make sure that we have a priority
value. Like
let's just say 120 on the left and maybe 110 on the right. And we need to have WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
let's just say 120 on the left and maybe 110 on the right. And we need to have
a decrement
design in place. So if this line protocol goes down, I want to decrement by,
let's say, 20.
So at this point, I'm tracking the object. I start with a priority of 120. If
this line
protocol goes down, I am reduced to 100 because I decrement the 20. And now
because I have
a higher priority on my standby and because I have preemption enabled, I will WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
a higher priority on my standby and because I have preemption enabled, I will
take over
as the FHRP active. Now, notice that the spanning tree blocking isn't going to
change. I'm still
going to send traffic up here and it will get hop over this way, but at least
even independent
of layer three issues, we can get routed upstream. And depending on the
situation, maybe we
do look at shutting down this link or whatever the situation is, but ultimately
what we care
about within FHRP object tracking is ensuring that our network stays online and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
about within FHRP object tracking is ensuring that our network stays online and
functional
when network failures occur that don't directly take the active node down.