Well, we've brought up the data center a few different times, and that's
because the
data center is a critical part of our network.
And yeah, I'll admit that I think data center technology is really cool.
I really like it a lot.
In fact, if you search for data center technology here at CBT Nuggets, you'll
find that I teach
a lot of the content.
And we all have our passions in life.
And I love the Nexus switches and UCS servers and storage networking that Cisco
brings to
the table.
But there's a better reason to bring it up than just because I like it. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But there's a better reason to bring it up than just because I like it.
And it's the fact that when we're talking about network redundancy, the data
center really
is arguably the most critical component of the entire network.
Yes, the core of the network matters as much as anything because if the core
goes down,
we lose access to the data center.
But the reason why it's so critical is because of what we just said before.
A lot of our users' jobs are tied to their ability to access applications.
And if we lose access to the applications, they can't do their jobs. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And if we lose access to the applications, they can't do their jobs.
They might as well go home.
And even though people might like to have that excuse, very rarely does it ever
result in
anybody actually getting to go home instead.
They have to very awkwardly deal with customers and deal with all of the
headaches that result
of them not having access to their critical applications.
So we need to provide a lot of redundancy in the data center because what the
applications
reside on are servers that connect into our access layer switches, as well as WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
reside on are servers that connect into our access layer switches, as well as
our storage
arrays and other appliances that all exist there inside the data center.
And as a result, even though this looks like an access layer because it lives
at the edge
of the network, it actually, and by the way, we do call it the access layer
outside of
the spine and leaf fabrics, but it provides a lot more resiliency, or at least
it needs
to provide a lot more resiliency than a campus access layer that shares the
same name. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
same name.
So the first thing we're going to do when we design a data center network,
especially
with a two tier or three tier model, is we're going to deploy a pair of aggreg
ation switches,
which behave very similarly to our distribution switches.
And then we are going to deploy access switches.
The difference here is that when I deploy access switches like this, and I
connect them
up to my aggregation layer, I'm going to ensure that my critical devices like WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
up to my aggregation layer, I'm going to ensure that my critical devices like
my servers
and my storage arrays and my appliances that they actually have redundant
connections upstream
to the access switches.
Now this upstream access is going to be a consideration logically, but also
physically,
because these devices are all in a rack somewhere inside of the data center.
And so if they're in the same physical rack, then how do they access both
switches?
Do they both go into the same rack? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Do they both go into the same rack?
Do we put a second rack over here?
And these switches have to connect down to all of those devices as well.
And this switch goes into this rack, and this switch goes into the rack over
here.
We've got some conversations to have there, but we do need redundancy from the
endpoints
here and the access layer, which is something we don't see in the campus
environment.
But it goes beyond just having redundant access switches, because the data WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But it goes beyond just having redundant access switches, because the data
center and specifically
Cisco Nexus switches, they give us a technology known as virtual port channels.
Now if we only live in the Cisco world, we probably again are going to use the
term Ether
channel, but the industry likes to use the word port channel because Ether
channel is a
Cisco word.
So when I talk about a virtual port channel, it's essentially just saying it's
a virtual
Ether channel, but it does get abbreviated as a VPC. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Ether channel, but it does get abbreviated as a VPC.
Here's the idea of the VPC.
If I have two switches like this and they're connected together, and I have
another switch
down here, looking like an aggregation access or distribution access to apology
, I can connect
down like this and we know spanning tree would require us to block one of those
connections.
Now if this was only going to one of these devices, then I could port channel
it and we
lose the redundancy of, you know, if this switch goes down again, that's a
single point
of failure, so we lose some redundancy, but at least we're not blocking WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of failure, so we lose some redundancy, but at least we're not blocking
spanning tree.
Well, usually we still go back to the old topology, which is to allow spanning
tree to block
a link because we need that redundancy in place.
Virtual port channeling aims to accomplish the benefits of both.
I'm going to put special configuration on these two devices, call them VPC
peers, and
this allows them to work some back end control plane magic with each other to
coordinate
turning this into a bundled connection. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
turning this into a bundled connection.
And we refer to this as the VPC.
As we see, it's a port channel that goes to two different devices which can
kind of break
our brains at first because I'm used to it being a one to one relationship.
Well it is one to one from the downstream perspective because this device
thinks that there's
this single device upstream that it's connecting to and so it's going to send
some traffic
out this way and some traffic out that way.
And this is again a wonderful way to achieve not only redundancy, but also WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And this is again a wonderful way to achieve not only redundancy, but also
efficiency, especially
since data centers often have, there might be 40 gig connections.
I'd really hate to spanning tree block of 40 gig or 100 gig or 200 gig
connection, and
that's going to be very costly.
Now this creates an interesting scenario with our first hop redundancy
protocols because
when we look at FHRP's in a VPC environment, here's what we might end up
happening or what WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
happening or what
we might end up seeing.
At the aggregation layer, I might have VLAN interfaces here, got a layer to
connection,
and so I'm going to deploy an FHRP because these servers and storage arrays,
they need to
get off their own subnet just like any other laptop or endpoint would need to
do.
So I wanted to play gateway redundancy, I deploy HSRP, I have an active over on
the left,
I have a standby over on the right, and then I'm going to turn these into VPC WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I have a standby over on the right, and then I'm going to turn these into VPC
peers and
connect down to this access switch.
And I'll create a VPC.
So so far so good, everything is perfectly fine.
So think about the traffic flow here, I just said that some traffic will get
load balanced
out this link, some will get load balanced out this link.
So if it gets sent out the first link, no problem, it arrives on the HSRP
active and it
gets processed and sent upstream because there's some upstream layer three
network above
the aggregation switch, usually the core layer. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the aggregation switch, usually the core layer.
So that looks great.
What if it gets sent out this other link?
Now it's landing on the standby.
And so it's going to have to get processed by the interface, well, it can't
because it's
the standby.
So it's going to have to forward it over to the active to get processed and
routed out.
So our efficiency is going to look like this every other packet, let's say,
whatever the
load balancing is, that can be perfectly per packet.
But some packets will get forwarded this way, some will get like this, some WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But some packets will get forwarded this way, some will get like this, some
will get like
that, some will go.
So we see that the problem is that half of our traffic is getting looped around
a very inefficient
path.
So what can you do here?
Well, by the letter of the law, there's not much we can do about this.
Fortunately, Cisco kind of breaks the law here.
And Cisco has said that, you know what, in this case, the standby for both HSRP
and VRRP.
So yes, that would be a VRRP backup, not standby. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So yes, that would be a VRRP backup, not standby.
But either way, the backup standby device is forward capable.
So that's kind of cool.
Basically what they're saying is, yeah, traffic might get sent to the HSRP
active.
It'll get processed and sent out.
But now traffic that gets sent to the standby can also get processed and sent
out.
How about that?
They can both respond when the destination Mac is the shared virtual Mac.
So that's pretty cool from a data plane perspective. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So that's pretty cool from a data plane perspective.
However, one caveat to that is that from a control plane perspective,
especially with how
our devices handle ARP responses, the ARP responses are still going to come
from the active node.
Meaning that if an ARP request gets sent here to the access switch, it might
well get
forwarded here to the standby. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
forwarded here to the standby.
I'll draw this in a different color here.
So our ARP request might get sent to a different device or to the standby
device.
It is going to forward it over and allow the active to handle the ARP responses
.
So just one small caveat and all of that.
But regardless, we do see how in the data center environment, if we're
deploying our first
top redundancy protocols to VPC peers, that fortunately we get this amazing
active, active
behavior that we will not get outside of the data center when we're deploying WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
behavior that we will not get outside of the data center when we're deploying
our FHRP's.
And yes, that does apply both to Cisco's HSRP, but also when we deploy the VRRP
onto
the Cisco Nexus devices.