[AUDIO LOGO]
Of course, another type of redundancy
that we need to be concerned with
is redundancy for the route processor.
Most of our routers in a service provider environment
will have redundant route processors or supervisor
engines.
The question comes in, what happens
when one of those supervisor or route processors fails?
We failover to the other one.
Locally, our line cards can continue forwarding traffic.
But what about our neighbors?
Will our neighbors still be able to continue forwarding traffic
to us?
Will they even know that they can continue forwarding traffic
to us?
That's what we're going be talking
about here with non-stop routing or NSR and graceful restart.
So let's go ahead and jump in, and we'll
talk about the attributes of each one of these.
So let's begin our discussion of these two technologies
with graceful restart.
Now the idea behind the graceful restart
is to allow the recovery of the control plane
without actually affecting the data plane.
Now this works the same as it does in routing protocols.
In other words, LDP is using the exact same mechanisms
that things like OSPF and IS-IS use,
so this is really using the same technologies.
Now this may or may not need to be enabled depending
on the platform, so graceful-restart on the LDP
configuration for IOS XR.
And if you're on IOS XE, it's mpls ldp graceful-restart
under global.
Now there sort of two parts to graceful restart,
which by the way, is also part of non-stop forwarding
and stateful switchover.
And the two parts are this.
One device has to have the dual route processors
and is the one that's capable of doing the switchover.
That would be the device that we would
have to issue these commands on to enable the feature.
The other half of this are the devices that,
while they may or may not be capable of doing
graceful restart, but they have to at least understand it.
What that means is when they get a graceful restart message
from their neighbor, they understand what it means,
and they'll continue forwarding the traffic,
as we're about to talk about here
in the next couple of steps.
But you don't have to enable these features just
to be the helper.
You only have to enable these features
if you want to be the one actually doing the switchover.
So again, the idea is when the capable device does
the switchover, the neighboring support LSRs that
support the non-stop forwarding and stateful switchover,
they will continue to forward the traffic
to the device that's doing the recovery.
How does it do that?
Well, first, traffic is going to be
forwarded using what's called the last known good
information.
So I'm not going to be updating my routing tables or anything
like that because, technically, our neighborship is
sort of suspended.
So in the case of LDP, I wouldn't be learning new labels
and things like that.
I would just maintain my database as I already know it.
So not only does this allow me to continue forwarding,
but it also allows for a much quicker recovery
because I already have the database.
All I would be doing is getting any changes
from LDP that have happened while the neighbor was
switching over.
Now, of course, we can't sit and wait for the recovering device
forever.
What if the switch over to the other route
processor on our neighboring device actually fails?
So if it does not recover in the allocated time,
well, it's going to be removed.
In other words, we'll just take the neighborship down
like we normally would.
If the device does reconnect, we will again
continue using the stale info, which
is the last known good configuration.
That's what it is.
But we'll continue using that while we resynchronize
the database and learn about anything
that changed while our neighborship was effectively
suspended.
So overall, this is a very effective system.
This has been around for quite some time.
And it's a tried and true technology
that we use again for routing protocols,
and LDP supports it as well.
But here's the thing.
A lot of our newer devices support
NSR, which is Non-Stop Routing.
Non-stop routing handles the entire process internally.
The neighbors never even know that a switchover occurred.
If the neighbors never know that a switchover occurred,
then there's no need for a graceful restart.
See, these are sort of mutually exclusive.
You can certainly configure both of them.
Don't get me wrong.
But non-stop routing pretty much makes
non-stop forwarding or graceful restart unnecessary.
Now NSR can be enabled simply typing nsr
under LDP configuration if your particular platform doesn't
have it enabled by default. Some platforms do.
Some platforms do not, so you'll want
to verify with your configuration guides
to see if you need to enable this
on your particular platform.
Of these two, clearly, we would prefer NSR.
It's the newer technology.
However, if your devices only support
graceful restarts / non-stop forwarding
/ stateful switchover, well, again, that's
a tried and true technology that's
been around for a very long time,
and it also works very well.
So in this video, we talked about graceful restart
and non-stop routing.
Graceful restart involves the neighbors.
The neighbors have to understand it.
We basically tell them we're doing a switchover,
but that's OK, go ahead and keep forwarding traffic
to me using the last known good information.
And then when the neighborship comes back up,
we use that old information and then just build on it
and refresh the information can make our database up
to date much quicker.
In the case of non-stop routing, it's all handled locally
so quickly the neighbors don't even
know the neighborship went down.
Therefore, there's no need for non-stop forwarding
to even exist when we're doing non-stop routing.
We certainly don't have to enable it.
Can we enable both?
Yes, on most platforms that I've seen.
But again, with non-stop routing,
there's really no need.
Something else that we might need to be concerned about
is in the event of other types of failures, maybe a router
reloads or something along those lines.
What would happen if LDP came up and synchronized
faster than our IGP did?
We might have labels and try to do label forwarding
before they're actually valid in our routing table
from our routing protocols.
So that's something that we may want to take a look at,
and that's exactly what we're going to do next.
Until then, I hope this has been informative for you,
and I'd like to thank you for viewing.