Well, this challenge is designed to help us bring together everything we've
been talking
about, FHRP's.
Everything from describing the different properties of the HSRP's when one
should be used over
the other, when one can be used, when one cannot be used, and then we want to
wrap up with
FHRP object tracking as well.
So if you haven't taken a moment to do this challenge, absolutely hit the pause
button
and go through this, it will help to solidify all of our understanding of what
we've been
talking about. And if you're ready to go and you've gone through this, then WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
talking about. And if you're ready to go and you've gone through this, then
well, let's
go start to go through this together.
So we're going to use this same topology for all of the individual challenges
or the individual
scenarios where we have router one and router two servicing a subnet, a VLAN, a
broadcast
domain, network segment, whatever we want to call it here, go in network
segment with
clients on it. And then they have upstream layer three connectivity as well,
which will
tie into the object tracking conversation.
So scenario one, our two routers are Cisco gateways. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So scenario one, our two routers are Cisco gateways.
We have VLANs in use ranging from 100 to 1500 and we want to match the group ID
to the VLAN
ID. So we've got a lot of reasons for why we might use one FHRP versus another
FHRP.
For example, the fact that we have Cisco gateways means that we can use HSRP
and GLBP,
but we can also use the industry standard VRRP as well. Cisco supports all of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
them. So we've
got all of them available, but it's going to be this requirement right here,
which helps
us to lock in the FHRP we're going to use. Because if we think about the
different FHRP's
we've talked about, HSRP version one and VRRP, these are going to support 256
groups and
specifically group IDs ranging from 0 to 255. We get 8 bits. And that comes WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
specifically group IDs ranging from 0 to 255. We get 8 bits. And that comes
back to the
virtual MAC address that's used because depending on which FHRP we're using, we
're going
to have a bunch of hex characters and then it's going to end with two hex
characters that
are defined by the group ID. So if we have a group ID of 15, well 15 is 0F in
hexadecimal.
And so the last two hex characters would be 0F in this case. So the fact that
we only have
two hex characters means that we have 256 group IDs available. Meanwhile GLBP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
two hex characters means that we have 256 group IDs available. Meanwhile GLBP
is a little
bit interesting because we actually have 10 bits, which is hard to represent
with just
X's and Y's as we demonstrated earlier in the videos. But 10 bits gives us a
thousand 24 group IDs
ranging from 0 to 1023. Now we want to be able to match up to 1500. And so none WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
ranging from 0 to 1023. Now we want to be able to match up to 1500. And so none
of these
FHRP's are going to actually be what's going to be are going to be eligible in
this scenario.
Instead we're going to need to look at HSRP version 2, which actually gives us
a full 12 bits.
And that gives us 4,096 group IDs ranging from 0 to 4,095. So what we get here
is a virtual
MAC address that ends with three full hex characters 12 full bits. And that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
MAC address that ends with three full hex characters 12 full bits. And that
allows us to match
even VLAN 1500 with a group ID of 1500. So the answer to scenario 1 is going to
be HSRP
version 2. If you got that right and you tracked with all of this, then we are
good to go
and we can move on.
Scenario 2. Router 1 and router 2 are non-sysco gateways. So that's a very
important aspect that
we need to be considering. Millicent timers are desired. And we'd also like to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we need to be considering. Millicent timers are desired. And we'd also like to
match the
FHRP group ID to the VLAN ID. Now to me, this is the most interesting scenario
because we have
router 1 and router 2 are non-sysco gateways. And we're immediately going to
look at that and say,
"Ah, okay, I want VRRP." And that would be correct. We do need a version of VR
RP here. And
the reason for that is non-sysco gateways aren't eligible to run Cisco
protocols and HSRP and
GLBP both of these are Cisco. We're only going to be able to run these on Cisco WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
GLBP both of these are Cisco. We're only going to be able to run these on Cisco
devices. So
as soon as we see non-sysco, these are not eligible. But we do still have two
versions of
VRRP. We've got version 2 and version 3, which leads us to the next bullet
point here,
which is that millisecond timers are desired. Well, VRRP version 2, along with
HSRP version
1, this is only going to allow us to perform second timers. And the default is
going to be a
hollow timer of 1 second, a whole timer of 3 seconds. But because I can't do WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
hollow timer of 1 second, a whole timer of 3 seconds. But because I can't do
millisecond
timers, that's as low as it gets from a hello perspective. So if I want to go
into the millisecond
range, I'm going to need VRRP version 3. The VRRP version 3 is going to give me
the ability to
have millisecond timers. And so far, we're good to go. VRRP can satisfy both of
these requirements.
But here's where it gets a little bit interesting. We also want to match the
group ID to the VLAN ID.
And we just said VRRP version 2 or version 3, both of these only support 256 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we just said VRRP version 2 or version 3, both of these only support 256
groups ranging
from 0 to 255. So if we have the same VLANs in place 100 through 1500, then we
're going to have a
problem here. Now, maybe we don't have VLANs in that range. We actually don't
even specify that
here within scenario 2. So if the assumption is, all right, as long as we've
got VLANs between 0 and 255, 0, I guess, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
got VLANs between 0 and 255, 0, I guess,
but VLAN 1 to VLAN 255, then we'll be good. Then, hey, all right, VRRP version
3 works for us. Otherwise,
this is going to be a condition that cannot be met. This is what the scenario
or maybe the challenge
description was talking about when it said, look for a design, you know, design
requirements that maybe
can't be met. These right here are conflicting requirements. Generally speaking
, we cannot guarantee WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
, we cannot guarantee
that we can match the FHRP group ID to the VLAN ID if we're using VRRP or GLBP
for that matter. It's
going to have to be HSRP version 2 at that point, but again, that's why it
conflicts with the first
bullet point because HSRP version 2 requires non-sysco gateways. So a little
bit interesting there, and
you might have taken it a different direction and said, well, okay, the
conflicting requirement is
this one, and we're just going to deploy HSRP version 2 again, but that one WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
this one, and we're just going to deploy HSRP version 2 again, but that one
would require us
purchasing new hardware and management would probably disapprove of that. So
scenario 3,
router 1 and router 2 are back to being Cisco gateways. All right, the Cisco
sales team is doing their job.
The desires for both gateways to be forwarding. So this one is probably a
little bit straightforward
because the whole purpose of GLBP, the gateway load balancing protocol, is to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
because the whole purpose of GLBP, the gateway load balancing protocol, is to
load balance between
two gateways. So if we're running HSRP or VRRP, all of our client traffic down
here is going to have
to go through the active gateway, which means that this guy over here is
sitting there bored. So GLBP
is the protocol we can deploy to allow for the load balancing of traffic out
both of these gateways.
And the way we do that is by having two different v-max. So we have v-max 1 on
the left, v-max 2 on the
right. And so if we have a client show up, it's going to think that its default WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
right. And so if we have a client show up, it's going to think that its default
gateway is pointing to
v-max 1 equals my gateway. Whereas the next host to show up is going to think
that v-max 2
represents its gateway. And this would be the load balancing mechanism that we
use. So remember,
one of these devices is going to be the AVG and it's going to handle the
distribution of the v-max.
So in some fashion, we're going to have roughly half the clients using v-max 1, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So in some fashion, we're going to have roughly half the clients using v-max 1,
half the clients
using v-max 2, and we have several load balancing algorithms to help us out
there. So the answer,
for scenario 3 is certainly GLBP. Let's just make sure we remember the
mechanisms for how GLBP works.
So let's scroll down a little bit here. We have a final scenario, which is
scenario 4.
So lastly, this organization recently experienced an outage on R1's uplink. So WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So lastly, this organization recently experienced an outage on R1's uplink. So
remember, both of these
routers have an activity up to the layer 3 domain. And apparently we lost
communication.
Let's change the color there. We lost access on this uplink. And even though we
've got redundancy for
our clients on these two routers, we lost connection. That's a terrible two.
That looks like a 3.
There we go. So we know that R1 is the active for HSRP. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
There we go. So we know that R1 is the active for HSRP.
And the question is, how can we prevent this in the future? Because our clients
should be able to use
the redundant path out router 2. But instead, clearly they were still going to
router 1.
And because router 1 didn't have a path to the rest of the network, the traffic
was just getting dropped.
So what we want to do is we want to leverage SHRP tracking, which is the answer
to the first question
here, which is what mechanism can be used. This would be object tracking. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
here, which is what mechanism can be used. This would be object tracking.
Object tracking is going to allow us to track the status of an object. In our
case, we've got a lot
of options here. I could track the actual link. I could track a IP address up
here. I could track
a route in the routing table, or I could leverage Cisco's IPSLA, which as we
mentioned is a whole other
suite of capabilities. So what's going to be tracked in this scenario,
specifically saying that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
specifically saying that
this uplink went down, we'd probably track the link itself, which as we recall
is the option called
line protocol. Basically saying, is this line, is this link online? So that
would be what we might
want to track. If you said that we would track the routing table to make sure
we have a route
upstream, or if you said that we would track an IP address or leverage IPL SLA,
there really is no
wrong answer to the second bullet point, as long as you were intentional with
what you were picking. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
what you were picking.
Now lastly, how are we going to force the failover? That is the goal after all.
We want to force
R1 to failover to R2, so that R2 can become the active, even though router 1 is
still online.
So what are we going to do? We're going to use dynamic priorities and that
decrement concept. So maybe
what we'll do is we'll say that router 1 has a priority of 150 and router 2
will have a priority WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
will have a priority
of 100. And we just need to set decrement values so that router 1 gets, you
know, lower than router 2.
So I could say I'm going to decrement this tracking, whatever it is we're
tracking. So we said we're
tracking the line protocol here, but I'm going to decrement by 100 if that link
goes down.
And so when the link goes down, my priority will drop to 50 and that'll be less
than 100 on the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
than 100 on the
other side. At that point it will prompt a failover question mark question mark
. We have to think
through there is one other mechanism that's very important to this process
because by default,
especially if we're running HSRP, which is what we're running, we do not
automatically failover,
even if our priority is lower than the other. So what do we need to do? We need
to deploy preemption.
So we would have to enable preemption at least on the backup node, but probably WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we would have to enable preemption at least on the backup node, but probably
on the primary note
as well in case it comes back online. That's typically what we do in real world
designs, but this is
the required part because once our primary goes down to 50, our active node, we
want the standby node
to be able to preempt to say I have a higher priority than you and that allows
me to become the
active. Now my clients can take the redundant path through router 2 and life
will be good. So that is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
will be good. So that is
a pretty fun scenario. The object tracking is something that is a requirement
in our network designs.
It's something that can very easily get overlooked in a lot of network
organizations. It might be time
to go out and make sure your own network is taking advantage of FHFHRP object
tracking because
chances are if we don't have object tracking in place, there could well be a
scenario where we're
either black holding traffic or if we do have a routing relationship between
those two routers, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
those two routers,
it will at least be inefficient and result in asymmetric routing as we
described in the previous
skill or a previous video earlier on in the skill. So that is a wrap up for FH
RP and object tracking
conversation. I hope this has been informative for you and I'd like to thank
you for viewing.