So, let's begin our First Hop Redundancy Protocol discussion with an overview of what First
Hop Redundancy Protocols are, and then we'll dive into HSRP specifically, VRP specifically,
as well as GLBP specifically.
So, why do we need First Hop Redundancy Protocols?
Well, so far, what do we have here?
We have three different VLANs.
We have VLAN10 in our case, VLAN20 in our case, VLAN50 in our case, as well as VLAN200.
We have our default gateways right now set up as Distribution 1 and Distribution 2.
So, for example, let's just focus on VLAN10.
We have interface VLAN10 here in our environment, and we configured it with 10.0.0.1 two sessions
ago.
And we configured this one with 10.0.0.2.
So, the question now is, which one of those addresses do I give to our PCs in VLAN10 as
their default gateway?
Well, you'll see here we have 10.0.0.1 configured.
Now, is it possible for us to provide both addresses?
Sure.
It is possible.
For example, if we look at this output here, we'll see that we have configured our PC in
its TCPIP settings with two default gateways.
So, we're relying on the PC to be able to figure out who the default gateway is.
Well, if both of them are running, that's pretty easy.
But what if PC1 chooses to use DSW1 and DSW1 fails?
How is it going to know to use DSW2?
It's not.
That's the thing.
It's not going to know.
So, what does that mean?
PC1 keeps sending traffic to DSW1 even though it's not available.
And what happens to it?
It simply just disappears.
It drops.
It doesn't get there.
So, we can't rely on the software settings of our end-user devices in order to get redundancy
when it comes to the default gateway.
It just doesn't work as we want it to.
We would have to rely on things like the ARP cache timing out.
And then when PC1 tries to get the MAC address of DSW1, it doesn't work.
So, then it goes after DSW2.
So, you see the challenges we face here?
It could take hours, days maybe, before PC1 starts using the other default gateway.
So, it's not going to work.
So, instead, what do we do?
We implement a feature, a service, on our distribution layer switches of first top redundancy
protocol.
And when we do so, we have the opportunity now to take these two physical devices and
create a virtual default gateway.
So, both DSW1 and DSW2 are physical multi-layer switches.
But what we're going to do is we're going to run a first top redundancy protocol and
now there is a virtual default gateway that both of them can use, both of them are responsible
for.
So, you'll see here this works with routers.
This works with layer 3 switches.
And what are we doing?
We're creating a group.
And when we create this group, what do we do?
We put the physical switches in that group.
So, I put DSW1 in that group.
I put DSW2 in that group.
And then this virtual default gateway is created for us and it creates the illusion of a single
default gateway.
So, this virtual router now is that default gateway.
And you'll see there's an IP address in that subnet specifically.
So, when you're creating your group, you're creating it for a specific subnet.
So, in this case, subnet 10.0.0.0.24.
I'm creating a virtual router with the IP address 10.0.0.0.254.
You can use any IP address you want as long as it's not an IP address that's already being
used in that subnet.
So, in this case, I chose 10.0.0.24, 254.
But it could be anything you want as long as it's not being used by anyone else.
When you do that, a MAC address will also be created for that virtual router as you
can see here.
So, the IP address is shared between these two physical routers.
The MAC address is now shared between these two physical routers.
And it is this IP address in this MAC address that is going to be given to our end station.
So, no longer are we going to be using the IP addresses of the interfaces.
We're going to use the IP address of this virtual default gateway instead.
And that's what we train our devices about.
So, you could put that in your DHCP pool.
So, when you create your DHCP pool for that subnet, that VLAN, that broadcast domain,
we put that IP address in there as the default gateway for that pool.
And that's what's given to your clients.
And so, now you'll see if you look at our ARP cache here, 10.0.0.254 is the ARP cache
for PC1.
You'll see that we have that MAC address that has been returned to us in this particular
case.
So, now that we've done this, what happens?
Well, it depends on the first top redundancy protocol that's being utilized.
If you're using HSRP or VRRP, what I'm about to show you is 100% true.
But if you're using GLBP, it's not 100% true.
We'll talk about GLBP later in its own discussion, and you'll see it's slightly different.
But for HSRP and VRRP, this is essentially what happens.
One device, one of these physical routers, DSW1 or DSW2, is going to have to be responsible
for everything in relation to this IP address and this MAC address.
So, for HSRP, we call it active and standby.
So, the active router is responsible for everything.
The standby router is just standing by.
With VRRP, we call it master and backup.
So, these routers have an election process.
They figure out who's who.
The active router is now going to be the one that is responsible for forwarding traffic.
So, it is the physical default gateway responsible for that IP address, responsible for that
MAC address.
It's going to respond to ARP requests.
So, for example, when PC1 sends out an ARP request, give me the MAC address of this IP
address.
Even if the standby device gets it, it ignores it, and DSW1 is the one who responds back
because it's active, therefore, that's how we get that.
In addition, the active router has to train the MAC address tables of all the other devices.
So, when it becomes the active router, it sends out what is called a GARP, a gratuitous
ARP, which is an ARP reply that never had an associated ARP request with it first.
So, I'm just sending out a GARP, and what that's going to do is it's going to train
ASW1, the MAC address, and the port, and, of course, the VLAN.
So, now ASW1 is pointing this way to that particular MAC address.
So, with this switch, it would point this way.
So, with DSW2, it would more than likely point that way.
Those are Layer 2 links instead of Layer 3 because DSW1 is our current default gateway
for that IP address and that MAC address.
So, all traffic right now for that VLAN is flowing this way.
So, what happens, though, if DSW1 fails?
Well, we have to realize that every three seconds, by default, these devices are talking
to each other.
They're talking to each other.
They're constantly updating each other about whether they are there or not.
So, if the active device fails, then this device will no longer hear from DSW1.
So, eventually, 10 seconds with HSRP, this device would be like, oh, you are really no
longer there.
So, I now have to become active.
So, I become the active device, and then what do I do?
I have to send a GARP out.
Why am I sending a GARP out?
I'm sending a GARP out so I can update the switches.
So, now look at ASW1's MAC address table.
The MAC address table now says, hey, it's out port channel 13.
It's this way.
So, what does that mean?
That means all the user's traffic was flowing this way.
As soon as this failed, by default, within 10 seconds, the user's traffic starts flowing
this way.
Now, 10 seconds seems like a long time, and it is, but you can absolutely fine-tune the
timers of HSRP so you can get sub-second convergence, which is highly recommended that you do.
And then, depending on how we configure the environment, when DSW1 recovers, for whatever
reason, maybe we had to intervene, maybe it just magically rebooted itself, and now it's
back online, what will happen is if we've configured it to do this, it will then take
over that active role again.
So, it takes over that active role, sends out the GARP onto the network so the MAC address
tables can be adjusted, so now ASW1 is going to be pointing this way again, and so now
the traffic just simply starts flowing this way again.
And in this case, because the transition is so fast, and it's going to happen, this device
comes up, it's like, okay, I'm up, all right, I'm going to take over the role, then typically
there is no traffic loss at all when you recover back over.
There may be a packet or two that goes missing when you've got a failover to DSW2, or a TCP
that will auto-recover for you, so that's not a big deal.
Even a voice conversation, not a big deal either, a packet or two for a voice conversation.
Human beings will just be like, oh, sorry, I missed that, can you repeat that?
You'll be fine, you'll be fine, right?
See how amazing this is?
This is awesome stuff.
But there's something you've got to think about, and it's something we brought to your
attention in every single session so far.
Other services and features have effects on other services and features here.
And so, one of the things we have to consider is spanning tree protocol.
Spanning tree protocol.
Think about it this way, if this is our root bridge for VLAN10, then what port would be
the root port?
It would be this port right here, and this would be blocked, and this would be blocked.
That would be a problem.
Why would that be a problem?
Because remember, this is the default gateway.
So what would happen is traffic would end up flowing this way, flowing this way, and
flowing out.
You see the problem?
You don't want traffic to flow like that.
So it's always imperative that your root bridge is the same device as the default gateway.
And therefore, your secondary root bridge should always be the same device that's going
to be your standby.
That way there, when you have a failover, both the root bridge and this device, the
root bridge goes here, and this becomes active.
When it fails back, it returns back to normal.
And this could get even worse for you.
Let's say, for example, this was the default.
No, let's say this was the default gateway here.
Let's say this was the root bridge down here.
Let's say this was the root port here, and this was blocked, blocked, blocked, blocked.
This was blocked, blocked, blocked.
It is possible, based on this topology, it's possible that your traffic could actually
flow like this.
And that's why, when we were talking about making sure your root bridge for Spanning
Tree Protocol is in the right place, it's not just for the sake of Spanning Tree Protocol,
it's for the sake of other services as well that you're depending on.
So, understand the dependencies, understand the gotchas with different protocols, is going
to be a key critical thing for you in the real world, so you can make better decisions
about your network.
So whenever you're working with a service going forward, always ask yourself, how does
this service affect my other services that I have running right now?
So, line up your Spanning Tree root bridge with your active forwarder at all times.
So, you want to be in complete control over all of this.
So, some things to keep in mind is that for every subnet, you're going to have to have
a group.
So, you can't have two different subnets in one group, okay?
So, you are going to have essentially a group for each and every single subnet that you
want to have the redundant default gateways.
So, I would have a group for this subnet, I'd have a group for this subnet, I'd have
a group for this subnet, and I'd have a group for this subnet, and you identify those groups
by a group number.
So, I could label these group 1, 2, 3, and 4.
I can label them group 10, 20, 30, 40.
I can label them any number within the numbering range that you're allowed, and it all depends
on the version of first hop redundancy protocol that you're using.
So, more on that later.
And then every single one of those groups is going to have a different IP address and
a different MAC address, and we'll talk more about that later.
So, when you think about your multilayer switches, you're configuring this feature, this service
on your SVIs.
That's what we're going to be configuring it on, our SVIs.
And so, we'd configure it on the SVIs here, we'd configure it on the SVIs here, and we'd
have to make sure that the parameters that need to match, match perfectly, or it's not
going to work for us.
All right.
What if you were using routers?
Let's say I had a router here, let's say I had a router here, we had two routers connected
to a switch, we had all of our user PCs down here.
Then we'd be doing it on the physical interface, the physical interface.
So, it's the default gateway for that subnet.
All right.
What about subinterfaces?
Well, then you'd be configuring it on the subinterfaces.
So, if you had subinterfaces instead, then you'd be creating it on the subinterfaces.
So, make sure you're aware of that for the exam.
So, if it's a diagram of two routers with subinterfaces, you're configuring it on the
subinterfaces.
If it's a diagram with just two physical interfaces, no subinterfaces, then you're configuring
it on the physical interfaces.
If it's a multi-layer switch, then you're configuring it on the SVIs.
All right.
So, these are the three different protocols we're going to have to know for the certification
exam.
Hot standby router protocol.
This is Cisco proprietary first top redundancy protocol.
It is the first, meaning this came out before the industry standard version of a first top
redundancy protocol.
So, we'll learn about that here today.
Provides redundant gateways where one is active, one is standby.
VRRP is the industry standard ripoff of HSRP.
So, here's a little bit of history lesson.
Cisco created HSRP.
It was used on Cisco devices.
Other vendors out there wanted that feature.
So, Cisco actually licensed it to other vendors for a fee.
So, it was implemented on other vendors' equipment, but they had to pay Cisco a fee.
Eventually, the industry banded together and created VRRP, an industry standard version
of HSRP, so that way they could stop paying Cisco.
But in the end, it behaves the same way with a few minor differences that really don't
matter.
Okay?
And then we got GLVP, which is Cisco proprietary, but this is cool.
This is so cool.
Provides you the ability to use all your default gateways for a single subnet, all right?
So, let's be clear here.
For this one and this one, you can only use one physical device at a time per subnet.
Meaning, for example, this could be active for this subnet, but we could have this one
active for this subnet.
That would be okay.
So, we could do like active, standby, active, standby.
This one could be active.
This one could be standby.
This could be standby, let's say, and this could be active here, all right?
So, we have the ability to use both at the same time as default gateways, so remember
when we were looking at our spanning tree protocol discussion yesterday, and it was
about manipulating the convergence of spanning tree protocol, that's what it was.
And we looked at this topology here, so I could have this as the active forwarder for
VLAN 10, and this could be the active forwarder for VLAN 50.
That's not a problem at all.
I can do that, but you can only have one physical device active at a time for that subnet slash
VLAN, right?
So, with GLBP, I can have up to four.
I can have up to four devices active at the same time, meaning forwarding traffic all
at the same time.
So, in this case, for example, we have VLAN 10 here, if you remember.
So, does that mean that PC1's traffic could go this way, and let's say PC2's traffic could
go this way?
Absolutely.
That's what GLBP lets me do, but now you have to think about spanning tree protocol.
Spanning tree protocol doesn't like GLBP.
GLBP doesn't like spanning tree protocol.
Why?
Because if this was my topology right now, and this is my layer two, layer three environment,
so this is all layer two, this is all layer three, as we've seen before, this would be,
let's say, the root port block, block, block, right?
For spanning tree protocol.
What does that mean?
It means that everyone has to go this way anyways, and then you would end up with traffic
flow like this.
This is silly.
You don't want this to happen.
So, having a spanning tree topology like this, your layer two environment like this, doesn't
play well with GLBP.
What you actually need to do to get GLBP working is to change your layer two, layer
three boundaries.
So, do something like this.
Now, this is all layer three.
So, you see how the links between distribution one and two are there?
Why?
Because that changes how spanning tree protocol is going to block ports.
Now, in this case, more than likely, if this is our root bridge, we're still going to end
up here with a root port here.
More than likely, these arrests are going to be blocked, because if you look, we still
have a figure eight loop here.
So, now that requires you to do filtering, right?
So, if you filter and you say 10 and 20 are allowed here, and 50 and 20 are allowed here,
and 10 and 20 are allowed here, and 50 and 20 are allowed here, what does that mean?
Okay?
So, that means now, in this particular case, that for VLAN 10, these are the only two links
in VLAN 10 right now, right?
So, there is no loop, because you've done your filtering, which means that this would
be a root port, and then we would have a designated port here.
We'd have a – nope, this would be blocked on this one.
This would be blocked here, and you might have something like that.
So, now that you have something like that, because you've done filtering and changed
your layer three, layer two boundary, now all of a sudden, you can use GLBP.
So, there's another great example of how, if you don't understand how one technology
works, you could be messing up your other technology, and a lot of people end up in
a situation where they implement GLBP, because they read about it, they think it's awesome,
which it absolutely is.
There's no denying that, but they have their network set up like this, they implement GLBP,
and they don't realize that all their traffic is doing this.
Well, then you might as well use – if that's what you're going to leave it as, you might
as well just use HSRP, because with HSRP, at least your traffic would do that.
So, these are the things you just got to be careful of in the real world when you're using
these technologies or learning about them.
It's about recognizing just some of the different little aspects about them that could make
or break your environment when it's all said and done.
All right.
So, that's our introduction to first-hop redundancy protocols.
Now, it's time to actually get into looking at HSRP.