[VIDEO LOGO]
So finally, we have trouble ticket 6,
and this is the ticket that is dealing with IPv6.
As such, it's going to be OSPFv3 topology 1.
So make sure we're referencing the correct topology here.
Now, the ticket itself is similar to the things
we've already seen.
We have R9.
So of course, we're going to be talking about up
here in area 1,000.
And it's saying that R9 is missing IPv6 routes
from both area 0 and area 200.
So that would be, of course, all the routes from here and here.
Now, just based on the topology and what
we know about how OSPF works, plus applying
a little bit of logic here, it seems
that there would have to be a virtual link between area
1,000 and area 0.
So this could theoretically be built either between, say,
R1 and R2, maybe R3 and R4.
So we'll have to get in and look at it,
but I'm pretty sure that it's built between R1 and R2.
So this seems like, just looking at it logically,
that it's a virtual link problem.
Now, we'll have to see if R9 has routes from,
say, maybe area 100.
We'll have to see what's going on here exactly.
But let's jump in and take a look and see what's going on.
So we'll start off here on router 9, verifying the ticket.
So let's do a show IPv6 route OSPF,
and we see that we do have some OSPF routes.
But again, these appear to only be the routes from area 100.
This further propagates the thought
that maybe this is a virtual link problem.
Let's go see what router 2 has.
So we'll do a show route IPv6, and we
see that router 2 appears to have all of the routes.
So this points even more towards this being a virtual link
problem.
Let's see if there even is a virtual link here on router 2.
So let's do a show OSPFv3 virtual.
We see that we do, in fact, have a virtual link
here, virtual link 0.
It's going to router 10.1.1.1, and it's
saying that it's up, up from the perspective of the virtual link
and the IPsec.
However, what we don't have here is an adjacency state of full.
So let's see what router 1 is saying about this.
So we'll do a show OSPFv3 virtual here.
So this site is saying that it's down.
So this is saying that we still have
this virtual linked to router 10.2.2.2,
but it's currently down.
Focusing on just this overall state of the virtual link
of being up or down, all the OSPF router really
does is look to see if it has a database entry for that router
ID.
If it has a database entry for the router ID,
it just assumes that the virtual link would be up.
And this would explain possibly why router 2 thinks it's up,
but router 1 thinks it's down.
It seems like one of them, specifically router 1 here,
may not have a database entry for the router ID of router 2.
Let's take a look and see if that's the case.
So let's do a show OSPFv3 database.
We'll look at the type I LSAs, specifically
from the advertising router 10.2.2.2.
Notice we have no entries.
So this isn't good.
But let's see if maybe router 2 has the entry for router 1,
and we can get an idea what it looks like.
So there's really two things here that we want to look at.
First, is we do, in fact, have an entry here
for the advertising router 10.1.1.1.
But there are two very important things
on this output that might be pointing us
towards the problem.
The first is right up here at the top, OSPFv3 router
with ID 2.2.2.2.
Plus, if we look down here at the topology information,
notice that the entry for router 1
is actually telling us that router 1's neighbor, which
is this router, router 2, has a neighbor router ID of 2.2.2.2.
So what's going on here is our virtual link
is built to 10.2.2.2 where router 2 is, in fact, set
to 2.2.2.2.
In other words, the first octet of the router ID on router 2
is incorrect.
Now, again, we have multiple ways to fix this.
First, we could just fix the virtual link on router 1
so that it, in fact, points to 2.2.2.2.
That would be OK and the virtual link would come up.
That would be a possibility.
The other possibility, of course,
is to change router 2's router ID
to be 10.2.2.2, which is actually
what all the other routers are set towards.
So again, even though either one of these solutions would work,
we're going to go with the changing the router
ID on router 2 just because, again, that's
consistent with the rest of the network.
So all we have to do here is go into configuration mode,
into router OSPFv3 1, set the router ID to 10.2.2.2,
commit the changes, and exit configuration mode.
Now that we've made this change, if we
take a look at the virtual link, well, router 2
thought that it was up, up before.
However, notice that we now have an adjacency state of full.
That indicates that it's actually
up with an OSPF neighborship.
So if we were to say show OSPFv3 neighbors,
we can see that we have a neighborship with router 1
specifically over the virtual link.
Let's go ahead and verify it from router 1's perspective
as well.
So once again, we'll just look at the virtual link.
Now, router 1 agrees that it's up, up.
Once again, we have that adjacency state of full.
And as our final test, of course, our original ticket,
does router 9 now have all the routes?
So back up on router 9, we'll simply repeat our
looking at the routing table.
And as we can see here, it certainly is a lot longer.
We don't have to look at every single prefix,
but that looks a lot better.
It's certainly a lot more routes than it had before.
In this video, we looked at an example in OSPF version 3
where we had a virtual link built,
but it was not built properly between router IDs.
Again, we could make the argument
that the virtual link wasn't built correctly
or we could make the argument that router 2's router
ID was not set correctly.
We decided to go with the option that router 2's router
ID was not set correctly.
And therefore, that's what we changed.
But remember, we could have also just reconfigured
the virtual link.
I hope this has been informative for you,
and I'd like to thank you for viewing.