[AUDIO LOGO]
Now we need to look at a couple of the advanced features
that we have with NSSA.
Specifically, we want to look at that translator
and how to control it.
There might be situations where we actually
care which router becomes the translator out
of our different ABRs.
So we'll take a look at how to control that.
And we'll take a look at the default route in NSSA.
As we've already seen, it doesn't actually
create a default automatically.
So we're going to be taking a look
at how we generate a default, and what
that looks like when we do.
So let's jump in and take a look at these different features
in NSSA.
So as we saw in our previous video,
we know that router 3 is currently the translator.
So let's take a look at what it would take to make
router 1 the translator.
And then as we already mentioned,
we'll also see what's involved in generating a default route
into the NSSA from our ABRs.
So let's go ahead, and jump in and get started.
We'll go ahead, and start on router 1
by forcing it to be a translator.
So we start by going into configuration mode, router ospf
1, area 100.
And on the NSSA command, notice we have a choice here
for translate.
If we say translate, there's actually
only one choice after this.
It's the type 7.
And there's only one choice after that,
which is to, say, always.
We'll commit that change.
And now let's do some verification.
If we say show ip ospf begin area 100,
notice that it now says, to perform the type
7 to type 5 LSA translation and to do it always.
That's because it's been manually configured to do so.
Now once router 1 has been configured
to be the translator, router 3 should
stop being the translator.
Let's go check it out on router 3.
But notice here, this actually is still
performing type 7 to type 5 translation.
Interestingly enough, router 3 hasn't stopped.
So the question is, is it really still doing that?
Let's jump over to router 7.
We just want to look at this from a different router.
We'll look at those external LSAs,
and look at the advertising router.
It is still 10.3.3.3.
So not only does router 3 think it should still be translating,
it actually is.
And this is actually due to an issue on IOS-XR--
how it handles not so stubby areas.
To see this, let's go to router 1.
Let's start by doing the show ip route ospf.
And we can actually see something interesting right
off the bat.
Notice that we're actually following the external type
2's.
If I say show ip ospf database external,
and then look at the internal processing,
we can see that the routing bit is actually set on this LSA.
We're using this type 5 from router 3.
Look at the advertising router.
We're actually following the translated LSA
that router 3 is generating.
And herein lies the problem.
Because if we look at the same thing, but for NSSA,
we have the type 7's.
But we're not using them.
And the problem is, if we're not using them,
we can't translate them.
Therefore, router 3 is staying as the translator.
Now, why is this?
Let's jump back over to our topology quick.
So again, what's happening here is,
router 9 is sending its routes, of course,
to router 2, who is redistributing
that, sending them as type 7's over to router 1.
And ultimately, down to router 3.
Router 3 is then, of course, translating this to a type 5
LSA and sending it up to router 1 to the rest of the network,
as well.
But we're concerned about router 1.
So that means that router 1 is receiving a type 5 LSA, as well
as a type 7 LSA for the same route.
And herein lies the problem.
IOS-XR follows RFC 1587.
And IOS-XE, starting right around version 1501,
actually uses RFC 3101.
So what's the difference between these, and why
is it important here?
Well, 1587 says to prefer external routes
in the order of E1s, then N1s, then E2s, and then N2s.
In RFC 3101, really to sort of address
the issue we're dealing with right here,
they changed this up.
In 3101, the order is, we prefer N1, then E1, then N2, then E2.
So we can see the problem here that with IOS-XR, following
RFC 1587, we can see now why router 1 is
making this decision.
It's preferring the E2 over the N2.
And as such, are forcing the translator isn't really
making the change that we thought it should.
But we have configured it properly.
And in the case of IOS-XE, this would be working as it should.
In the case of IOS-XR, it is technically working.
But it will not actually function
as expected because of this RFC 1587 issue.
So now that we've talked about the translator,
let's go ahead and talk about that default route.
In order to have an external route to be able to test with,
we're going to go ahead and change area 200, which
is currently a stub.
We are going to change this so that it's no longer a stub.
So we're going to change area 200 back to a normal area.
Let's hop over to router 6.
So of course, we'll just go into router ospf.
And we'll just say no area 200 stub.
Of course, our neighbor ship will go down for a moment
until we can figure router 10.
Same configuration here.
And the neighbor ships should come back up.
Let's verify we have reachability now
from, say, router 7.
So here on router 7, let's just do a show ip route ospf.
And we'll do a section of E2 just
to look at the external routes.
And we see that we are, in fact, learning that 100.10.10.0/24
now from router 10.
And we can just verify that we can reach it.
.10 is the actual host address, and we
can see that it's working.
So now let's look at this from router 5.
Remember that router 5 is inside the NSSA.
So again, if I say show ip route ospf, the first thing we know
is that we have no default route.
And the gateway of last resort is not set.
Remember that external cannot come in, because this is still
a stub.
It's just a special type of a stub.
If we were to say show ip cef for the 100.10.10.10,
what we find is that it's telling us it would follow
the default, but it doesn't have one.
So it's telling us the route that it would match on--
0.0.0.0/0.
But that there is no route for that.
That's because there's no default route here.
That, of course, also means that it will not work.
This should time out.
We can, of course, see here that it is.
So clearly, we need a default.
Let's configure router 1 to send a default route into the NSSA.
We simply go into the router ospf process.
We'll go into area 100.
Say NSSA.
Say default-info.
We can tab that out.
We can see it's a rather long command,
default-information-originate.
And we have our other options here.
But let's just go ahead and hit Enter.
We'll commit those changes.
And let's go back and check on router 5 again.
We do our show ip route ospf.
We see that we now have an N2.
So it's a type 7 LSA coming in as a default.
Now the reason this is brought in as a type 7 for the default
is, again, maybe I have a default coming in
from another protocol.
And that's also coming in as a type 7.
Maybe what I want to do is follow that other route
as my primary default. And maybe I
would set a higher metric on this one,
and use this one as a backup.
If I brought this in as another LSA type.
For example, if I brought this in as a type 3 LSA,
then I would have absolutely no choice but to follow
the internal OSPF default. I would not
be able to follow an external default.
By bringing it in as a type 7, it still
gives us as the administrators the option
to choose which one we want to use.
Now in this case, we're just bringing in the 1.
So that's not really an issue here.
But just be aware that that's why
it's brought in as a type 7.
Now, of course, we can verify our other commands now.
To show ip cef for 100.10.10.10, we can see that it's still
going to follow that default route.
But now it actually has a route.
Particularly, heading up towards router 2
and then over towards router 1.
It also means we should be able to ping our address.
We can see that that's working fine.
However, if we do a show ip ospf database nssa,
particularly for the 0.0.0.0 entry,
notice we're only receiving one.
And this is because we only configured router 1.
You would normally want redundancy here.
So we should configure router 3 as well.
Router 3 is the same configuration as router 1.
So we'll just paste it in, and go back and verify on router 5
again.
So first, if we look at our database again,
we now have two entries--
one from router 1, one from router 3.
So we'll do a show ip route ospf.
And we can see that we have both entries in our routing table.
If we look at the details for that route,
we can see that it's actually load sharing on both
of those routes.
So now we're not only getting the default,
but we're also load sharing.
In this video, we took a look at two more advanced features
that we have on NSSA.
First, we took a look at how to control the translator,
even though on IOS-XR following RFC 1587,
it doesn't exactly work as expected.
However, we did still see how to control that.
And we talked about how to do the
default-information-originate into the NSSA
and saw how that brings it in as a type 7 LSA.
I hope this has been informative for you.
And I'd like to thank you for viewing.