[AUDIO LOGO]
Let's go ahead and move on with trouble ticket 4.
Once again, still on MPLS topology 3.
And according to this, router 6 is not
receiving any routes from the customer A remote sites.
So this is a fairly straightforward ticket.
Let's go ahead and jump into router 6
and see if we configure what's going on.
So of course, let's begin by verifying our ticket.
So here on router 6, we'll just do a show IP route.
It's saying we're not getting any routes
from the remote site.
And we see here that that appears to be correct.
We have connected our local routes, but that's it.
We have no routes from what should be OSPF.
So I think the first step would be
to verify that we are running OSPF here on router 6.
So let's do a show IP OSPF interface brief.
And what we see here is that we are, in fact, running
OSPF on the gigabit 1 interface, which
is our interface facing the service provider or router 1.
So that appears to be correct.
Let's do a show IP OSPF neighbor.
Let's see if we have a neighborship with router 1.
We can see that, in fact, we do.
The neighbor state is full.
And of course, that is connected out of our gigabit 1 interface
as we would expect.
So we do appear to be running OSPF,
and we do appear to have neighborships.
Let's try a show IP OSPF database
because it is possible that we're
receiving the updates through OSPF, but for whatever reason,
they're not making it to the routing table.
So if we look at our show IP OSPF database,
we do see that we have a type I LSA here for router 1.
So again, we are getting information from that device,
but that's all that we have.
So let's try and get a little bit more information from that.
Let's ask for router 10.1.1.1.
So again, we definitely are getting a type I LSA.
It's actually advertising the point-to-point network
between router 6 and router 1.
Now, that wouldn't show up in OSPF because, well, that's
a connected network.
But unfortunately, that's all it's advertising to us.
And if we, of course, did a show IP OSPF rib,
we see that, yeah, we know about our own loopback.
Of course, we do.
We know about 10.100.6 that's also connected to this device
on loopback 100.
And we know about the 192.168.16.0, the link
between router 1 and router 6.
But none of these are the routes from the other side.
And we can also see that none of these
are installed in the global rib.
Of course, the reason they're not installed in the global rib
is even though we're either learning them from OSPF
or this router's injecting them into OSPF,
one way or the other, all three of these
are local on this router.
They're connected interfaces.
So of course, we're not going to follow OSPF
when we have connected routes.
So the main point in all of this, OSPF
looks like it's functioning perfectly fine on router 6.
It looks like we have a neighborship with router 1.
And router 1 is, in fact, sending us
database entries or LSAs.
So it seems like it's probably time
to jump over to router 1 and maybe get a look at what's
going on over there.
So here on router 1, let's see if we even
have the routes in the VRF.
So let's do a show IP route for the VRF customer A.
So what we see here is a combination
of OSPF and BGP updates.
Now in this case, of course, the OSPF routes
are coming from router 6.
So those aren't what we're really concerned
about right now.
We're more worried about the BGP updates.
So we see here that we do, in fact, have BGP updates.
We can, of course, filter this.
Router 1 is learning the routes from the other side.
So let's see if it's actually putting them into OSPF.
So let's do a show IP OSPF for the process 100.
That's the customer's process.
If we didn't remember, we could, of course, look.
We could start with a show IP protocol.
So we can see that we have the routing process OSPF 100.
So if we didn't remember exactly which one it was, of course,
we could look.
But now that we verified it, we can
do a show IP OSPF 100 database.
And let's filter by self-originated.
So again, here's a spectacularly empty list of all of the LSAs
that we're generating here on router 1.
So clearly, there's a problem here
with getting the routes from BGP,
which we do have into OSPF.
So there's something going on with the redistribution.
Maybe it's being filtered.
Maybe it's not configured at all.
There's a couple of options here,
but it's probably time to take a look
at how it's actually configured to do that redistribution.
So let's go ahead and do a show run.
And we'll begin with OSPF.
Of course, we'll be looking for OSPF process 100.
We do see that it is in the proper customer VRF.
Our domain ID is configured.
Under the address family under area 0,
we do have our interface, and it is configured for point
to point.
But what we do not have is any redistribution of BGP.
So this definitely appears to be a problem.
Let's go ahead and fix that and see if it resolves our issue.
So we'll go into configuration mode,
router OSPF 100 into the VRF for customer A,
and we'll say redistribute BGP 100.
Commit our changes.
And exit configuration.
So now that we have our redistribution done,
let's go ahead and jump back over to router 6
and see if this is resolved our issue.
So on router 6, if we do our show IP OSPF database again,
we see that clearly now, we have a whole bunch more entries.
And if we do our show IP OSPF rib again,
we can see that now, we have a lot of these prefixes that
are actually installed in the global rib, which
means if we do our show IP route, we'll filter by OSPF.
We now have all of our OIA entries
for the networks on the other side.
So it seems like this completely resolves this ticket.
So in this video, we saw how missing something
as simple as redistribution in our MPLS layer 3 environment
can, of course, break the entire thing.
We were missing all of our routes on router 6
simply because router 1 wasn't doing
the proper redistribution.
Now, we didn't look at this specifically in this ticket.
However, from our previous tickets,
we already know the routes we're getting
from router 6 to the other side because, well, that
had some issues too, and we've already resolved those.
So we already know that redistribution
was working one way.
It just wasn't working the other.
So now that we have this resolved,
we have the routes on router 6 just as we're supposed to.
I hope this has been informative for you,
and I'd like to thank you for viewing.