Well, another form of network redundancy we should consider has to do with
hardware redundancy,
but we're not just talking about having two sets of hardware, we're talking
about within
a set of hardware.
Because if I have a fixed configuration switch, meaning it's just a single rack
unit, a bunch
of ports on it, and it has a hardware failure, well, the whole thing has gone
down.
And ideally, I have a second device here, and I can redirect my traffic from
one device
to the other. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to the other.
But what about a network device like a chassis switch?
A chassis switch is built to be modular, and there are two different types of
modules.
We have the supervisor, which is the intelligence part of the chassis, and then
we have individual
line cards.
So the supervisor is really in charge of the control plane, and the line cards
are what
handle the data plane.
Now let's make sure that we have a good grasp of control plane versus data WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now let's make sure that we have a good grasp of control plane versus data
plane, because
the idea of a chassis being redundant is that we would have two supervisors,
and if one
of these supervisors goes down, the active supervisor, then we would want this
device to stay
online and operational.
But we can't just say that, well, we have two supervisors, and so we're good to
go.
We're going to need some techniques on the back end in order to make sure that
everything
stays forwarding.
And it does have to do with the control plane and the data plane.
So when we think about it, if a packet comes in to a device, we're going to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So when we think about it, if a packet comes in to a device, we're going to
check some
kind of table.
And this table is going to determine how we forward it.
So this might be a routing table at layer three.
It could be a cam table at layer two, but it's going to allow us to pick a port
and
forward it out.
And this would be known as the data plane of operations.
Well that's well and good, except where does this table get its information? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well that's well and good, except where does this table get its information?
Well that would be the control plane.
So I'm going to run a protocol like EIGRP or OSPF or at layer two.
I'm just going to learn the control plane by forwarding traffic, and I populate
this
table.
And the way I do that at the control plane is by forming adjacencies with other
devices.
So I've got another device over here.
I've got another device over here.
And I am forming a partnership with them with the EIGRP and adjacency at OSPF, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And I am forming a partnership with them with the EIGRP and adjacency at OSPF,
the terminology
changes.
But in the end, we're exchanging information with one another so I can form the
information
that goes into those tables that enable the data plane.
So once again, thinking about the fact that my supervisor has just gone down
and the supervisor's
in charge of control plane operations, meaning I'm bringing packets in and
evaluating
them and changing the table if needed and all of those things. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
them and changing the table if needed and all of those things.
Well if I lose the control plane, then I have just lost the information that I
was populating
in the table.
And so as a result, the data plane goes down.
This is the danger that we have in this scenario.
And so we have to think through, okay, what is the failover process going to be
looking
like?
Well when we look at things from a classical perspective, back when chassis
switches
first came out, we had a cold standby procedure. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
first came out, we had a cold standby procedure.
Cold standby said that we have a redundant supervisor.
So that's good.
In fact, we'll just call this the failover supervisor.
So we have a failover soup and it is waiting for the primary to fail.
As soon as the primary fails, we're going to boot up that supervisor, which is
going to
take some time, then we are going to form those adjacencies or those neighbors WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
take some time, then we are going to form those adjacencies or those neighbors
hips with other
devices and then we're going to populate the table.
But notice the entire time that the control plane is sitting here working, the
data plane
is actually down.
We don't have any information in those tables.
So this could actually be several minutes of downtime.
Now is that better than being down for hours waiting for new hardware to show
up?
Sure. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Sure.
But that's still minutes of an outage that we might think that we could do
better with,
especially since our failover supervisor is sitting there inside the chassis.
So instead, we're going to develop a couple of procedures and processes that's
going
to enable us to do this faster.
And it's going to involve two separate processes, the first of which is known
as stateful switchover,
which is abbreviated as SSO. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
which is abbreviated as SSO.
The idea of stateful switchover is to maintain the state of operation while the
switchover
is happening.
This is going to involve a couple of facets to this, but really what it
involves is the
fact that I need to maintain the control plane.
Here's the problem.
If I have two supervisors and the active is here on the left and the redundant
ones there WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
ones there
on the right, I have all of my tables populated here on the supervisor.
And the tables over here are completely empty.
So if supervisor A goes down, I can't forward traffic.
Again, the data plane has gone down because I lost all the information that was
sitting
there in the table.
So what stateful switchover says is, first of all, we're going to have the
redundant
soup online and fully synchronized. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
soup online and fully synchronized.
We're going to sync the control plane information.
What this means is that if I populate information into the table for the active
soup, I'm going
to populate the table here in the backup soup as well.
This improves my ability to fail over in one important way, which is, first of
all, the
redundant soup is already online.
Meaning that I don't have to power this thing up from a cold standby
perspective.
But the other thing to consider is the fact that I'm actually synchronizing the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But the other thing to consider is the fact that I'm actually synchronizing the
control
plane.
And that creates an interesting situation.
Because when we look back at our diagram at the top here, if the control plane
now goes
down, meaning the supervisor failed, we still have a table that is fully
populated here
on supervisor B, meaning that the data plane can stay online.
Now there might be still a few seconds for us to detect that the primary is
down.
And then therefore we're going to have to maybe still drop some packets for a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then therefore we're going to have to maybe still drop some packets for a
few seconds.
But as soon as we direct our traffic through this backup supervisor, this table
is fully
populated and the data plane is online.
Now that's well and good, other than the fact that we do still have another
problem, which
is that we had these adjacencies and we were maintaining the information from
our adjacencies
as part of maintaining the control plane operation.
So we need a mechanism to maintain those relationships. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we need a mechanism to maintain those relationships.
And so that is going to lead us to non-stop forwarding.
Actually, we'll write it out here.
Non-stop forwarding or NSF.
Not forwarding is going to help us to basically maintain the adjacencies or the
neighborships,
depending on whether we're running OSPF or EIGRP, Jsoncees. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
depending on whether we're running OSPF or EIGRP, Jsoncees.
So we're going to be able to maintain those adjacencies.
In order to do this, we're going to have to let the other devices know that we
have NSF
enabled.
And first of all, we enable NSF ourselves.
And then we let the others know that we are NSF capable.
We say, hey, by the way, we would like to use NSF here in case we go down.
And by the way, we need both of these devices to also be NSF capable. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And by the way, we need both of these devices to also be NSF capable.
So this is something that is going to be requiring support at multiple levels.
Not only on the chassis, but also on the remote devices.
But the idea here is that when we go down, we have an amount of grace time to
get back
online.
Because we might be running millisecond timers and we might say, hey, you've
been down for
a second and a half.
I'm going to completely drop this connection, which means I'm updating the own WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I'm going to completely drop this connection, which means I'm updating the own
info or the
info in my own routing table.
We don't want a whole convergence event.
We don't want everybody to be shifting routes around.
Instead, the idea here is that we're essentially, we're going to freeze the
control plane, at
least as far as the information that involves this one chassis.
Now how long are we freezing this?
Well, overall, this should happen in a matter of seconds, as we mentioned.
We have to detect that there's an outage.
We have to flip over to the redundant supervisor. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We have to flip over to the redundant supervisor.
Then we need to activate that and get it online and start sending control plane
information.
For several seconds, we're going to be in a place where we have to trust that
this information
hasn't changed.
If there are changes, there's routes that have changed or routes that are no
longer valid,
well, I'm going to still be forwarding traffic out my interfaces as if that
information is
valid because this table was frozen in time during the NSF process. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
valid because this table was frozen in time during the NSF process.
What it does is it prevents these adjacencies from going down and it allows the
other devices
to know, okay, we're in the middle of an NSF event here, clearly.
We're going to show some grace while that device figures it out.
Once it's online, we don't have to reestablish the adjacencies.
We maintain those adjacencies and it keeps the layer three network stable.
In the meantime, the NSF capable device out here, it's going to mark its routes
as stale,
meaning that they haven't been updated in a while, they might not be up to date WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
meaning that they haven't been updated in a while, they might not be up to date
.
Then, so this is the first step here, and the second step is then I'm going to
send a graceful
restart message to say I'm back online and functional.
At that point, if any information had changed while that device was down, we'll
get that
update being sent from the NSF capable devices and we will be back online and
functional,
so hopefully the network was just stable and we took a few seconds to switch
over to the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
new supervisor and everything stays online.
We never dropped any adjacencies.
Our neighbors never had to pull any routes and it keeps our layer three network
online and
stable even through this hardware failure.
[BLANK_AUDIO]