[AUDIO LOGO]
So let's begin by talking about two technologies that help us
with convergence performance in the event of a route processor
failure.
The first one we're going to look at
is NSF, or non-stop forwarding.
And the other one is NSR, non-stop routing.
Now, these do perform the same basic role.
So generally speaking, if we have NSR, we don't need NSF.
So we'll talk about that as we go through the details
of each one.
Something else to note here, we can see this a little bit
on the command line in our lab.
So we'll jump in and look at that.
But be aware that our lab is all virtual routers,
and they do not have redundant route processors.
Therefore, we can't actually see this in operation.
But the most important thing is to understand what it does
and how both of these technologies work.
So let's go ahead and jump in and talk about the details.
And then we'll see what little bit
we can see at the command line.
So as we said during the introduction, NSF,
or non-stop forwarding, and non-stop routing, or NSR,
are both technologies that help us with--
well, we say stability here or with convergence
during RP switchovers, hopefully,
avoiding any convergence time at all, particularly
with NSR, non-stop routing.
So let's jump in and talk about more details
on each one of these.
Let's start with NSF.
So the idea here is it allows forwarding
to continue, hence the name non-stop forwarding,
using known routes.
Of course, if the route processor fails,
that means that our neighborships and such will go
down in our routing protocols.
So the idea with these known routes, well, twofold.
First, our neighbors have to use the routes they already
knew to forward traffic to us.
And we have to use the routes that we already
knew that are learned on our line cards.
So this will be doing forwarding based
on already known information until the failover is complete.
Now, as we jump into detail here,
be aware that there are two versions of this.
There is a Cisco proprietary version
and an IETF standard version.
Cisco routers can support either one.
We'll talk about that here as we go.
Now, the routers themselves fall into three categories.
The first is what we call NSF-capable.
This is the router that we would say is actually
doing the non-stop forwarding.
This is the router that has the dual-route processors.
Keep in mind none of this can happen
unless the router has dual-route processors because, of course,
we're failing over to the other one.
That's the point.
Part of what it's going to have to do after the failover is
it's going to have to relearn the IS-IS neighbors.
And the key here is we have to do this without causing
actual neighbor resets.
If we reset our neighborships, we
will wipe out the IS-IS database and have
to learn everything over again.
Being able to rebuild the neighborships
without a full reset does require that we
have the link-state database.
Now, once the neighborships come up,
we will refresh that link-state database and recalculate
anything we need to.
And there's one more super key factor for this to work.
We have to signal our neighboring routers
that a failover is occurring.
Our neighbors here are going to have to be aware
that we're doing a failover.
The reason this is so critical is otherwise,
when our route processor goes down
and our neighborships go down, just
like we would remove all the routes from our routing table
if it weren't for non-stop forwarding,
so would the neighbors.
They basically have to be told, it's OK.
We're a dual-processor system.
We're failing over the other route processor.
We can still forward traffic with our line cards.
Keep sending us traffic.
Now, it, of course, doesn't say all that,
but that's the implied meaning.
We're telling our neighboring routers
that we're still capable of forwarding traffic
so they know to keep sending it to us.
It also lets them know that we'll
be doing a soft rebuild on the neighborship.
In other words, we won't be tearing down the neighborship
and rebuilding it.
We'll be rebuilding the neighborship,
resynchronizing our databases, and then going back
to normal operation.
Now, of course, in order for this to work,
there's another requirement.
That requirement is quite simply that we have
to have an NSF-aware neighbor.
The neighbor has to recognize that signal
that the NSF-capable router sent us.
If we don't recognize this signal,
we wouldn't to keep forwarding traffic
to the NSF-capable router.
Now, the key factor here is these routers
do not need dual processors.
As far as I am aware, all Cisco routers are NSF-aware.
Again, they're not all capable because they don't all
have dual-route processors, but they're all aware.
Now, part of what this aware router is going to do,
as we've already implied, is that it's
going to preserve the IS-IS link-state database
and the routing table.
That way, it continues forwarding traffic,
even though the other router is failed over or failing over
or we've lost the neighborship essentially.
And then we allow that soft rebuild
to happen on the neighborship once the NSF-capable router
comes back online.
So it's not that the NSF-aware router really
has to do anything spectacularly special here,
but it has to be aware of what's going on
and what the process is.
Now, unfortunately, there is a third category here,
and that is a non-NSF aware router.
And these quite simply just do not participate in NSF.
And if a route processor failure happens,
we're just going to have to form a neighborship
and come back up just like normal.
So non-NSF aware routers aren't going
to participate in this at all.
Now, we did already mentioned this, but just as a reminder
that after the recovery, everything
is going to be reconverged.
We're going to update any and all tables as needed, mostly,
of course, meaning the link-state database
and the routing table, but these will be updated
after everything comes back online.
The second feature, of course, is NSR, or non-stop routing.
This is a little bit different.
It still allows failover and process restart or even ISSU,
which is our in-service software update--
but here's the really cool part--
without affecting neighbors.
This doesn't involve the neighbors at all.
I don't care what they're capable of,
what they're not capable of.
This is all done on the router that supports NSR.
The way this works is it uses something
called warm standby extensions.
And we run a standby IS-IS process on the standby RP.
This is kept fully synchronized with the active route
processor.
That way, if it fails, the standby
can take over almost instantly.
And it's certainly faster than any of our routing protocols
would detect a neighbor failure.
Since this is all happening in-house
and it happens so fast that our neighbors don't even
realize it, this really does just
alleviate the need for non-stop forwarding.
We don't need to be running both of these at the same time.
And what we're going to see is that most of our newer devices
are starting to support NSR.
And therefore, we'll see that non-stop forwarding isn't
necessarily enabled by default. Now,
we're going to jump into the command line in just a minute
and look at this.
And we'll see that non-stop forwarding is not enabled
by default on these devices.
But I want to make sure we're clear we
understand what that means.
It means that it's not NSF-capable,
NSF-aware is always on.
If a neighbor tells us that it's doing non-stop forwarding,
we'll go, OK, and that function works.
We're talking about if this device itself is NSF-capable.
So we're going to look at the topology
just real quick just so we know which devices we're looking at.
And then we're going to jump into the command line
and see, again, what little we can
see about these technologies without actually
having dual-route processors.
So for this skill, we'll be using IS-IS Topology 1.
And in this particular video, just
so we can see IOS XR and IOS XE, we'll
just be looking at the command line on router 1 to get IOS XR
and on router 5 to get IOS XE.
So that said, let's jump into the command line on router 1
and take a look at what commands we do have available to look
at NSF and NSR.
So if we start here on router 1 with just a show isis protocol,
first thing we can see here is that non-stop forwarding
is disabled, as we mentioned.
It is disabled by default. And again, this
is because non-stop routing is enabled by default.
This output doesn't really show that.
But if we do a show nsr forwarding for the client
trace process isis, we can actually
see that this is enabled for isis1.
So it's not the cleanest output, but this
is the best way that I'm aware of to verify that NSR is
actually enabled and operating.
Again, it's a default, so it's not generally shown.
Now, we can enable non-stop forwarding on this platform
if we want to, but again, the fact
that it's running non-stop routing
negates the need for it.
So that said, if you did want to enable it,
they're the same commands that we're
about to look at on router 5 on IOS XE.
So now, let's go look at router 5.
Again, if we do a show isis nsf for non-stop forwarding,
we see that non-stop forwarding is also
disabled on these platforms as well.
Now, this platform is not going to be running non-stop
routing because this platform is not capable of having
redundant route processors.
However, we can take a look at how
we would turn on non-stop forwarding if we wanted to.
We simply go into configuration mode,
go into our router process.
And under NSF, we can see we have a few choices here.
Of course, we can turn on the Cisco method.
We can turn on the IETF method.
By the way, we can turn on both.
We can also configure interface properties or set the interval.
So we're not going to actually turn this on.
We don't really have a need to in our lab environment.
But this is how we would normally configure it.
In this video, we took a look at two technologies
that we can use to help with route processor
failover or switchover.
The first was non-stop forwarding,
which involved a cooperative effort between our neighbors
and the route that's having the failover, where they really
communicate with each other and understand that we're going
to keep forwarding packets until the routing protocol comes back
online again.
The second choice, which is also a newer choice,
is non-stop routing.
And in this case, the standby route processor
is kept in full sync with the active route processor
so that when a failover does have to occur,
it's so fast that the neighbors don't even know it happened.
It's almost instantaneous.
I think it's 50 milliseconds on most platforms
that it'll switch over to the standby route processor
and just keep right on forwarding traffic,
keep right on running the routing protocol just
like nothing changed at all.
I hope this has been informative for you.
And I'd like to thank you for viewing.