[AUDIO LOGO]
Moving right along, we're on trouble ticket 5 now.
We are still on MPLS topology 3, and we have yet sort
of another easy ticket.
Router 9, which is our customer A remote site 2 over here,
is not receiving the routes from customer A headquarters.
So we've had previous tickets similar to this, of course,
on router 8, and now it seems that it's router 9's turn
not to have the routes.
So let's, of course, jump over to router 9
and see if we can figure out what the issue is.
As always, let's start with verifying the ticket.
We'll just do a show IP route here on router 9.
And we see that we are, in fact, not getting the routes
from the headquarters.
In fact, we don't have any routes
at all, which in and of itself is incredibly suspicious.
The reason it's suspicious is we don't even
have any connected or local routes.
We have no routes at all.
Let's do a show IP interface brief
and see if our interfaces are even configured.
So we can see here that gigabit 1 and gigabit 2
are properly configured with their IP addresses
as they should be.
Having interfaces configured with IP addresses
and those interfaces being up up,
yet not having local or connected routes
in our routing table really sort of screams
that these must be in a VRF.
So let's take a look at this from the perspective of maybe
there's a VRF here on router 9.
So let's do a show VRF, and yep, here we
see we have a VRF named WAN, and in that VRF are the loopback
0, loopback 100, the gigabit 1, and the gigabit 2 interfaces.
So now let's take a look at this from the VRF.
So let's do a show IP route VRF WAN.
Now, once again, we're not going to care too much
about the local and connected, so let's go ahead
and filter this out and just focus on the OSPF routes.
We do have some OSPF routes here as we can see,
but notice that they're all from router 8.
So it means we're getting local OSPF routes
into our VRF, but not the ones from headquarters,
which of course, is what the ticket said.
So now we have sort of a better validation
that the ticket is correct.
We have OSPF routes from the local site,
but not from headquarters.
So let's find out if they're in the database.
Let's do a show IP OSPF database,
these would be coming in as type 3 LSAs or summaries,
and we know that there should at least be 10.6.6.6,
which is router 6's loopback.
So let's pick on something we know should be in the database
here on router 9.
So we see that we are, in fact, getting these entries
into the database, but if we do a show IP OSPF RIB,
let's see if they're being entered into the routing table.
Notice that some of these are installed into the global RIB,
but some of them are not.
And notice that the entries from the other side,
again, are not even listed here.
So not only are they not making it
into the global routing table, they're
not even making it into the OSPF RIB, or Routing Information
Base.
So maybe we should take a closer look at those database entries.
We can scroll up or we could just repeat that last command
there and looking over these entries,
we see something here that hopefully would jump out at us.
We now know that router 9 is running OSPF in a VRF.
And if we look at these database entries,
we should see that the downward bit flag is set.
And we know that if OSPF is running in a VRF
on a Cisco router, that it implements PE loop prevention.
So let's look at this a little bit closer
and see if that's what's actually going on here.
If we do show IP OSPF, another sort of giveaway
here as to whether we're doing PE loop prevention
is notice right here where it says that it is an area border
router.
This router thinks it's an ABR.
Now, if we were to say show IP OSPF interface brief,
all of its interfaces are in area 0.
So realistically, it shouldn't think that it's an ABR.
However, notice this statement right here.
It says that it's connected to MPLS VPN Superbackbone
through the VRF WAN.
So yes, it thinks it's a PE, it thinks
it's connected to the MPLS VPN Superbackbone, which of course,
it's not, because router 9 is not even running MPLS.
So not only does it think that it's
connected to the superbackbone, but that also
would make it an ABR, and therefore it's
enforcing loop prevention based on the downward bit.
Now, we know we have a fix for this.
In order to get a router to not enforce PE loop prevention when
it's running OSPF in a VRF, we need
to use the capability VRF Lite.
So let's turn that on here on router 9
and see if it fixes our issue.
We simply go into configuration mode into router ospf 1,
and it's simply capability vrf-lite.
We'll end our configuration.
Now, we see here that it does bounce
all of its neighborships.
So you could make the argument that you should do this
during a maintenance window, but the flip side of that
is this wasn't working anyway, that's
why we're here troubleshooting the router.
So doing it right in the middle of the day
might not be a problem if we're actually fixing a problem.
So now that it's reset all of its neighborships, let's
see what's changed.
Let's go ahead and start with that show IP OSPF.
Now, unfortunately, I can't highlight on our screen
something that's not here.
But if you look over this and maybe
if you rewind a little bit and look at the previous output
to see where it's supposed to be, you might notice, A,
that this no longer says that it's connected to the MPLS
Superbackbone, neither does it say that it's an ABR.
So that's one good indicator that it no longer
thinks that it's a PE.
Of course, another good one would be show IP OSPF RIB,
and we see now that we do, in fact,
have the entries from router 6-- there are two of them here--
not counting the transit link, which we're not
concerned with right now.
But we have the 10.6.6.6/32 and the 10.100.1.6/32,
which are both routes over at headquarters.
And if we do a show IP route VRF WAN and we filter for OSPF,
we see that now we are getting those O IA
routes coming from router 6, those entries
that we were just discussing.
So capability VRF Lite did in fact fix our issue.
So in this video, we saw an example
of a customer using a VRF, in this case
called WAN, to run their OSPF instance for their VPN
connections.
Now, there's nothing wrong with this
and a customer may choose to do this
for a variety of different reasons.
However, we did see a side effect here.
First, it means that it's going to implement PE loop
prevention, which means it's going
to be looking at that downward bit set in the OSPF LSAs.
And if the downward bit is set on the route,
we will not use it.
Now, it, of course, is still in the database--
and we saw that--
but it doesn't get eligibility for entry
into either the OSPF RIB or the global RIB.
The router also thinks that it's connected
to the MPLS Superbackbone, and therefore is an ABR.
Now, to fix this, of course, since the customer does,
in fact, want to use a VRF, but they are not,
in fact, going to be running MPLS,
this is where the capability VRF Lite comes into play.
It essentially says to the router,
yes, you are running OSPF and yes, it's in a VRF,
but that doesn't automatically make you a PE.
So don't be PE, you are not connected to the MPLS
Superbackbone, you're not going to have to do loop prevention,
looking at the downward bit, and you're not an ABR.
And that's of course, it actually was an ABR,
but in this case, it wasn't because all of its interfaces
were in area 0.
So at the end of all of this, we just have to remember to sum
this up that if you're going to use OSPF with a VRF on any
router really-- but it would commonly be
on the customer's router--
that we have to do capability VRF Lite,
or else that router is going to think
that it's a service provider PE router and act accordingly.
So this definitely fixed our problem and everything
is working just fine now on router 9.
I hope this has been informative for you,
and I'd like to thank you for viewing.