1
00:00:00,000 --> 00:00:03,423
[VIDEO LOGO]

2
00:00:03,423 --> 00:00:13,220

3
00:00:13,220 --> 00:00:16,970
So finally, we have
trouble ticket 6,

4
00:00:16,970 --> 00:00:21,560
and this is the ticket
that is dealing with IPv6.

5
00:00:21,560 --> 00:00:27,170
As such, it's going to
be OSPFv3 topology 1.

6
00:00:27,170 --> 00:00:30,140
So make sure we're referencing
the correct topology here.

7
00:00:30,140 --> 00:00:32,990
Now, the ticket itself
is similar to the things

8
00:00:32,990 --> 00:00:34,470
we've already seen.

9
00:00:34,470 --> 00:00:36,170
We have R9.

10
00:00:36,170 --> 00:00:38,540
So of course, we're going
to be talking about up

11
00:00:38,540 --> 00:00:40,490
here in area 1,000.

12
00:00:40,490 --> 00:00:44,840
And it's saying that R9
is missing IPv6 routes

13
00:00:44,840 --> 00:00:49,460
from both area 0 and area 200.

14
00:00:49,460 --> 00:00:53,300
So that would be, of course, all
the routes from here and here.

15
00:00:53,300 --> 00:00:56,810
Now, just based on
the topology and what

16
00:00:56,810 --> 00:01:00,830
we know about how OSPF
works, plus applying

17
00:01:00,830 --> 00:01:03,080
a little bit of
logic here, it seems

18
00:01:03,080 --> 00:01:07,460
that there would have to be
a virtual link between area

19
00:01:07,460 --> 00:01:10,400
1,000 and area 0.

20
00:01:10,400 --> 00:01:13,700
So this could theoretically
be built either between, say,

21
00:01:13,700 --> 00:01:17,900
R1 and R2, maybe R3 and R4.

22
00:01:17,900 --> 00:01:20,100
So we'll have to get
in and look at it,

23
00:01:20,100 --> 00:01:24,170
but I'm pretty sure that
it's built between R1 and R2.

24
00:01:24,170 --> 00:01:27,530
So this seems like, just
looking at it logically,

25
00:01:27,530 --> 00:01:29,850
that it's a virtual
link problem.

26
00:01:29,850 --> 00:01:33,780
Now, we'll have to see
if R9 has routes from,

27
00:01:33,780 --> 00:01:35,810
say, maybe area 100.

28
00:01:35,810 --> 00:01:38,390
We'll have to see what's
going on here exactly.

29
00:01:38,390 --> 00:01:42,500
But let's jump in and take a
look and see what's going on.

30
00:01:42,500 --> 00:01:45,950
So we'll start off here on
router 9, verifying the ticket.

31
00:01:45,950 --> 00:01:49,330
So let's do a show
IPv6 route OSPF,

32
00:01:49,330 --> 00:01:52,540
and we see that we do
have some OSPF routes.

33
00:01:52,540 --> 00:01:56,950
But again, these appear to only
be the routes from area 100.

34
00:01:56,950 --> 00:01:59,680
This further
propagates the thought

35
00:01:59,680 --> 00:02:02,150
that maybe this is a
virtual link problem.

36
00:02:02,150 --> 00:02:06,180
Let's go see what router 2 has.

37
00:02:06,180 --> 00:02:08,810
So we'll do a show
route IPv6, and we

38
00:02:08,810 --> 00:02:13,770
see that router 2 appears
to have all of the routes.

39
00:02:13,770 --> 00:02:17,900
So this points even more towards
this being a virtual link

40
00:02:17,900 --> 00:02:18,960
problem.

41
00:02:18,960 --> 00:02:22,880
Let's see if there even is a
virtual link here on router 2.

42
00:02:22,880 --> 00:02:26,360
So let's do a show
OSPFv3 virtual.

43
00:02:26,360 --> 00:02:28,700
We see that we do, in
fact, have a virtual link

44
00:02:28,700 --> 00:02:30,710
here, virtual link 0.

45
00:02:30,710 --> 00:02:34,460
It's going to router
10.1.1.1, and it's

46
00:02:34,460 --> 00:02:38,780
saying that it's up, up from the
perspective of the virtual link

47
00:02:38,780 --> 00:02:40,310
and the IPsec.

48
00:02:40,310 --> 00:02:45,410
However, what we don't have here
is an adjacency state of full.

49
00:02:45,410 --> 00:02:49,850
So let's see what router
1 is saying about this.

50
00:02:49,850 --> 00:02:54,000
So we'll do a show
OSPFv3 virtual here.

51
00:02:54,000 --> 00:02:56,180
So this site is
saying that it's down.

52
00:02:56,180 --> 00:02:57,680
So this is saying
that we still have

53
00:02:57,680 --> 00:03:00,440
this virtual linked
to router 10.2.2.2,

54
00:03:00,440 --> 00:03:03,960
but it's currently down.

55
00:03:03,960 --> 00:03:07,350
Focusing on just this overall
state of the virtual link

56
00:03:07,350 --> 00:03:11,430
of being up or down, all
the OSPF router really

57
00:03:11,430 --> 00:03:16,980
does is look to see if it has a
database entry for that router

58
00:03:16,980 --> 00:03:18,120
ID.

59
00:03:18,120 --> 00:03:20,760
If it has a database
entry for the router ID,

60
00:03:20,760 --> 00:03:23,760
it just assumes that the
virtual link would be up.

61
00:03:23,760 --> 00:03:28,890
And this would explain possibly
why router 2 thinks it's up,

62
00:03:28,890 --> 00:03:31,350
but router 1 thinks it's down.

63
00:03:31,350 --> 00:03:35,850
It seems like one of them,
specifically router 1 here,

64
00:03:35,850 --> 00:03:42,120
may not have a database entry
for the router ID of router 2.

65
00:03:42,120 --> 00:03:45,360
Let's take a look and
see if that's the case.

66
00:03:45,360 --> 00:03:49,450
So let's do a show
OSPFv3 database.

67
00:03:49,450 --> 00:03:53,440
We'll look at the type
I LSAs, specifically

68
00:03:53,440 --> 00:03:56,560
from the advertising
router 10.2.2.2.

69
00:03:56,560 --> 00:03:58,700
Notice we have no entries.

70
00:03:58,700 --> 00:04:00,250
So this isn't good.

71
00:04:00,250 --> 00:04:03,315
But let's see if maybe router
2 has the entry for router 1,

72
00:04:03,315 --> 00:04:05,065
and we can get an idea
what it looks like.

73
00:04:05,065 --> 00:04:08,750

74
00:04:08,750 --> 00:04:11,590
So there's really two things
here that we want to look at.

75
00:04:11,590 --> 00:04:14,380
First, is we do, in
fact, have an entry here

76
00:04:14,380 --> 00:04:17,829
for the advertising
router 10.1.1.1.

77
00:04:17,829 --> 00:04:20,769
But there are two
very important things

78
00:04:20,769 --> 00:04:23,410
on this output that
might be pointing us

79
00:04:23,410 --> 00:04:24,640
towards the problem.

80
00:04:24,640 --> 00:04:29,680
The first is right up here
at the top, OSPFv3 router

81
00:04:29,680 --> 00:04:33,760
with ID 2.2.2.2.

82
00:04:33,760 --> 00:04:37,850
Plus, if we look down here
at the topology information,

83
00:04:37,850 --> 00:04:41,110
notice that the
entry for router 1

84
00:04:41,110 --> 00:04:45,220
is actually telling us that
router 1's neighbor, which

85
00:04:45,220 --> 00:04:52,880
is this router, router 2, has a
neighbor router ID of 2.2.2.2.

86
00:04:52,880 --> 00:04:56,540
So what's going on here
is our virtual link

87
00:04:56,540 --> 00:05:02,810
is built to 10.2.2.2 where
router 2 is, in fact, set

88
00:05:02,810 --> 00:05:05,000
to 2.2.2.2.

89
00:05:05,000 --> 00:05:10,100
In other words, the first octet
of the router ID on router 2

90
00:05:10,100 --> 00:05:12,030
is incorrect.

91
00:05:12,030 --> 00:05:15,470
Now, again, we have
multiple ways to fix this.

92
00:05:15,470 --> 00:05:20,270
First, we could just fix
the virtual link on router 1

93
00:05:20,270 --> 00:05:24,260
so that it, in fact,
points to 2.2.2.2.

94
00:05:24,260 --> 00:05:26,870
That would be OK and the
virtual link would come up.

95
00:05:26,870 --> 00:05:28,680
That would be a possibility.

96
00:05:28,680 --> 00:05:30,570
The other possibility,
of course,

97
00:05:30,570 --> 00:05:34,250
is to change router
2's router ID

98
00:05:34,250 --> 00:05:39,500
to be 10.2.2.2,
which is actually

99
00:05:39,500 --> 00:05:41,780
what all the other
routers are set towards.

100
00:05:41,780 --> 00:05:46,073
So again, even though either one
of these solutions would work,

101
00:05:46,073 --> 00:05:47,990
we're going to go with
the changing the router

102
00:05:47,990 --> 00:05:51,260
ID on router 2 just
because, again, that's

103
00:05:51,260 --> 00:05:54,120
consistent with the
rest of the network.

104
00:05:54,120 --> 00:05:58,970
So all we have to do here is
go into configuration mode,

105
00:05:58,970 --> 00:06:06,430
into router OSPFv3 1, set
the router ID to 10.2.2.2,

106
00:06:06,430 --> 00:06:10,250
commit the changes, and
exit configuration mode.

107
00:06:10,250 --> 00:06:12,430
Now that we've made
this change, if we

108
00:06:12,430 --> 00:06:15,610
take a look at the virtual
link, well, router 2

109
00:06:15,610 --> 00:06:17,990
thought that it
was up, up before.

110
00:06:17,990 --> 00:06:23,320
However, notice that we now
have an adjacency state of full.

111
00:06:23,320 --> 00:06:25,810
That indicates
that it's actually

112
00:06:25,810 --> 00:06:27,950
up with an OSPF neighborship.

113
00:06:27,950 --> 00:06:31,300
So if we were to say
show OSPFv3 neighbors,

114
00:06:31,300 --> 00:06:35,350
we can see that we have a
neighborship with router 1

115
00:06:35,350 --> 00:06:38,690
specifically over
the virtual link.

116
00:06:38,690 --> 00:06:41,050
Let's go ahead and verify it
from router 1's perspective

117
00:06:41,050 --> 00:06:41,780
as well.

118
00:06:41,780 --> 00:06:44,030
So once again, we'll just
look at the virtual link.

119
00:06:44,030 --> 00:06:46,720
Now, router 1 agrees
that it's up, up.

120
00:06:46,720 --> 00:06:49,360
Once again, we have that
adjacency state of full.

121
00:06:49,360 --> 00:06:53,080
And as our final test, of
course, our original ticket,

122
00:06:53,080 --> 00:06:56,810
does router 9 now
have all the routes?

123
00:06:56,810 --> 00:06:59,290
So back up on router 9,
we'll simply repeat our

124
00:06:59,290 --> 00:07:00,950
looking at the routing table.

125
00:07:00,950 --> 00:07:04,480
And as we can see here, it
certainly is a lot longer.

126
00:07:04,480 --> 00:07:06,880
We don't have to look
at every single prefix,

127
00:07:06,880 --> 00:07:08,930
but that looks a lot better.

128
00:07:08,930 --> 00:07:12,890
It's certainly a lot more
routes than it had before.

129
00:07:12,890 --> 00:07:18,180
In this video, we looked at
an example in OSPF version 3

130
00:07:18,180 --> 00:07:20,480
where we had a
virtual link built,

131
00:07:20,480 --> 00:07:25,400
but it was not built
properly between router IDs.

132
00:07:25,400 --> 00:07:27,410
Again, we could
make the argument

133
00:07:27,410 --> 00:07:29,900
that the virtual link
wasn't built correctly

134
00:07:29,900 --> 00:07:32,960
or we could make the argument
that router 2's router

135
00:07:32,960 --> 00:07:35,360
ID was not set correctly.

136
00:07:35,360 --> 00:07:39,020
We decided to go with the
option that router 2's router

137
00:07:39,020 --> 00:07:40,400
ID was not set correctly.

138
00:07:40,400 --> 00:07:42,170
And therefore, that's
what we changed.

139
00:07:42,170 --> 00:07:45,050
But remember, we could
have also just reconfigured

140
00:07:45,050 --> 00:07:46,820
the virtual link.

141
00:07:46,820 --> 00:07:48,890
I hope this has been
informative for you,

142
00:07:48,890 --> 00:07:51,880
and I'd like to thank
you for viewing.

143
00:07:51,880 --> 00:07:55,000