1
00:00:00,000 --> 00:00:03,960
[AUDIO LOGO]

2
00:00:03,960 --> 00:00:13,390

3
00:00:13,390 --> 00:00:16,360
Next up, of course,
is Trouble Ticket 4.

4
00:00:16,360 --> 00:00:20,980
This is, once again,
using OSPF topology 3.

5
00:00:20,980 --> 00:00:22,940
For this one, we have
a little bit more

6
00:00:22,940 --> 00:00:24,320
of an interesting statement.

7
00:00:24,320 --> 00:00:27,470
This is saying not that we
don't have neighborships,

8
00:00:27,470 --> 00:00:32,780
but we have inconsistent
neighborships, particularly

9
00:00:32,780 --> 00:00:34,520
on R7.

10
00:00:34,520 --> 00:00:37,550
So, of course, that means
we'll be looking at R7

11
00:00:37,550 --> 00:00:39,080
and what we'll
have to do first is

12
00:00:39,080 --> 00:00:41,240
figure out which neighborships.

13
00:00:41,240 --> 00:00:43,970
Now in our previous
video, we just

14
00:00:43,970 --> 00:00:47,360
did a ticket between
router 7 and 8,

15
00:00:47,360 --> 00:00:51,270
and that seems to be
consistently up and working.

16
00:00:51,270 --> 00:00:53,300
So we're either
going to be looking

17
00:00:53,300 --> 00:00:56,150
at the neighborship
with router 3

18
00:00:56,150 --> 00:01:01,730
or the neighborship
with routers 6 and 1.

19
00:01:01,730 --> 00:01:04,700
So let's jump into
router 7, and get started

20
00:01:04,700 --> 00:01:06,890
and figure out first
which neighborships

21
00:01:06,890 --> 00:01:08,250
we're talking about.

22
00:01:08,250 --> 00:01:10,430
And then, of course,
we'll try to figure out

23
00:01:10,430 --> 00:01:11,910
what's going on with them.

24
00:01:11,910 --> 00:01:16,020
So let's jump into
router 7 and get started.

25
00:01:16,020 --> 00:01:19,860
So here on router 7 let's do
our show ip ospf neighbors.

26
00:01:19,860 --> 00:01:24,290
And we see that it's currently
neighbors with 6 and 3

27
00:01:24,290 --> 00:01:25,550
as well as 8.

28
00:01:25,550 --> 00:01:30,080
But again, we're going to assume
that 8 is OK here since we just

29
00:01:30,080 --> 00:01:32,060
did this in the last ticket.

30
00:01:32,060 --> 00:01:34,700
Let's look at this a couple more
times because the ticket did

31
00:01:34,700 --> 00:01:36,450
say inconsistent.

32
00:01:36,450 --> 00:01:38,390
So if we look at
this a few times,

33
00:01:38,390 --> 00:01:40,070
it actually looks like it's OK.

34
00:01:40,070 --> 00:01:42,050
Now a lot of times
when you're having

35
00:01:42,050 --> 00:01:44,690
neighborship issues
with OSPF, it

36
00:01:44,690 --> 00:01:46,890
will generate console messages.

37
00:01:46,890 --> 00:01:50,420
So us being in through
SSH, it may not

38
00:01:50,420 --> 00:01:53,930
be a bad idea to turn
on terminal monitor

39
00:01:53,930 --> 00:01:56,570
because a lot of times we'll
see things happening, of course,

40
00:01:56,570 --> 00:02:00,110
live where we don't necessarily
see them in the outputs of show

41
00:02:00,110 --> 00:02:00,830
commands.

42
00:02:00,830 --> 00:02:03,650
So with terminal monitor on,
let's give this just a second

43
00:02:03,650 --> 00:02:05,690
and see if we get
any kind of message.

44
00:02:05,690 --> 00:02:08,210
Well, here we have a message
that router 6 just came up,

45
00:02:08,210 --> 00:02:09,949
and then router 6 went down.

46
00:02:09,949 --> 00:02:13,550
And then router 1 came up,
and then router 1 went down.

47
00:02:13,550 --> 00:02:15,140
And now router 6 is back up.

48
00:02:15,140 --> 00:02:17,600
This is clearly
some inconsistency.

49
00:02:17,600 --> 00:02:19,920
Now, this is going to be a
little hard to work around.

50
00:02:19,920 --> 00:02:22,585
So let's do term
no mon again just

51
00:02:22,585 --> 00:02:24,710
to turn those console
messages back off while we're

52
00:02:24,710 --> 00:02:26,210
trying to work through here.

53
00:02:26,210 --> 00:02:28,400
And another good
thing to do might

54
00:02:28,400 --> 00:02:32,480
be to get an idea of how
long this has been going on.

55
00:02:32,480 --> 00:02:36,060
Did this just start, or
is it a long-term problem?

56
00:02:36,060 --> 00:02:38,660
So a good way to find
that, of course, especially

57
00:02:38,660 --> 00:02:41,300
since we know it's been
generating console messages,

58
00:02:41,300 --> 00:02:43,100
would be to do a show log.

59
00:02:43,100 --> 00:02:45,380
If we look at our
show log, we actually

60
00:02:45,380 --> 00:02:48,720
see that it is full
of these messages.

61
00:02:48,720 --> 00:02:51,050
So it looks like it's
been going on probably

62
00:02:51,050 --> 00:02:53,990
since this router
booted up or since I

63
00:02:53,990 --> 00:02:57,420
loaded these configurations on
here, causing these problems.

64
00:02:57,420 --> 00:03:00,500
So this has been up and
running for quite some time,

65
00:03:00,500 --> 00:03:02,130
causing these issues.

66
00:03:02,130 --> 00:03:04,170
So we definitely
see what's going on.

67
00:03:04,170 --> 00:03:06,110
And then it's been
going on for a while.

68
00:03:06,110 --> 00:03:10,580
Our neighborships are flapping
between router 1 and router 6.

69
00:03:10,580 --> 00:03:11,870
But why?

70
00:03:11,870 --> 00:03:13,700
What's causing this?

71
00:03:13,700 --> 00:03:17,100
Let's start with a show
ip ospf interface brief.

72
00:03:17,100 --> 00:03:20,300
And let's take a look at
that interface that goes out

73
00:03:20,300 --> 00:03:22,400
towards router 6 and router 1.

74
00:03:22,400 --> 00:03:24,890
Specifically, that's gigabit1.

75
00:03:24,890 --> 00:03:30,110
Notice that gigabit1 is showing
that it has one neighbor.

76
00:03:30,110 --> 00:03:32,480
It does have one
neighbor, doesn't it?

77
00:03:32,480 --> 00:03:34,820
First, it has router
1 as a neighbor.

78
00:03:34,820 --> 00:03:36,980
Then it has router
6 as a neighbor.

79
00:03:36,980 --> 00:03:39,140
Then it has router
1 is a neighbor.

80
00:03:39,140 --> 00:03:43,190
So it only has one
neighbor at a time,

81
00:03:43,190 --> 00:03:48,140
but that's currently
flapping between R1 and R6.

82
00:03:48,140 --> 00:03:50,300
And we can actually
see the problem

83
00:03:50,300 --> 00:03:53,360
right here on the screen
already without going

84
00:03:53,360 --> 00:03:55,770
any further
depending, of course,

85
00:03:55,770 --> 00:03:59,160
in your environment how much
you trust the network diagram.

86
00:03:59,160 --> 00:04:01,070
If we look at our
network diagram,

87
00:04:01,070 --> 00:04:05,660
the connection
between R7, R6, and R1

88
00:04:05,660 --> 00:04:08,040
is a multi-access network.

89
00:04:08,040 --> 00:04:09,830
In other words, it's
a single sub-net.

90
00:04:09,830 --> 00:04:13,040
All three of those routers
should be neighbors.

91
00:04:13,040 --> 00:04:17,029
The problem is this is
configured as point-to-point.

92
00:04:17,029 --> 00:04:21,980
And a point-to-point OSPF
network type, by definition,

93
00:04:21,980 --> 00:04:24,800
means you can only
have one neighbor.

94
00:04:24,800 --> 00:04:27,740
There's only two devices on
a point-to-point connection,

95
00:04:27,740 --> 00:04:30,510
yourself and your neighbor.

96
00:04:30,510 --> 00:04:35,030
So, in this case, it's trying
to bake a neighborship.

97
00:04:35,030 --> 00:04:38,060
And as soon as router 1
sends a hello, it goes,

98
00:04:38,060 --> 00:04:39,590
oh, you must be my neighbor.

99
00:04:39,590 --> 00:04:40,850
It forms a neighborship.

100
00:04:40,850 --> 00:04:43,185
And then next thing you
know, router 6 sends a hello,

101
00:04:43,185 --> 00:04:44,810
and it goes, wait,
wait, wait a minute.

102
00:04:44,810 --> 00:04:47,310
OK, you must be my
neighbor on this segment.

103
00:04:47,310 --> 00:04:50,660
So it switches over, and it
becomes neighbors with router 6

104
00:04:50,660 --> 00:04:53,300
just in time for router
1 to send a hello again

105
00:04:53,300 --> 00:04:55,670
and-- you see how this
is going to progress.

106
00:04:55,670 --> 00:04:57,500
As it's receiving
these different hellos

107
00:04:57,500 --> 00:05:00,380
from these neighbors, it's
just flapping back and forth,

108
00:05:00,380 --> 00:05:04,700
trying to figure out which one
other neighbor its supposed

109
00:05:04,700 --> 00:05:06,060
to be neighboring with.

110
00:05:06,060 --> 00:05:08,090
So, of course, the
fundamental problem

111
00:05:08,090 --> 00:05:11,730
here is we have the
wrong OSPF network type.

112
00:05:11,730 --> 00:05:15,200
Now, as we approach this
problem, what we have

113
00:05:15,200 --> 00:05:17,570
to consider is how to fix it.

114
00:05:17,570 --> 00:05:20,300
We need an OSPF
network type here

115
00:05:20,300 --> 00:05:22,880
that will support more
than one neighbor.

116
00:05:22,880 --> 00:05:25,730
So we could, of course,
go to the default

117
00:05:25,730 --> 00:05:29,510
here for an Ethernet connection,
which would be broadcast.

118
00:05:29,510 --> 00:05:31,760
Technically, we could
do non-broadcast

119
00:05:31,760 --> 00:05:35,610
as well, but honestly, that's
not done very often anymore.

120
00:05:35,610 --> 00:05:37,490
There's also a few
other choices here.

121
00:05:37,490 --> 00:05:41,570
We could set this up as
point-to-multipoint and/or

122
00:05:41,570 --> 00:05:44,570
the point-to-multipoint
non-broadcast option.

123
00:05:44,570 --> 00:05:49,130
But point-to-multipoint
could also work here but not

124
00:05:49,130 --> 00:05:53,670
if we don't change our neighbors
to be point-to-point as well.

125
00:05:53,670 --> 00:05:57,980
We can't actually bring this
up as just point-to-multipoint.

126
00:05:57,980 --> 00:06:00,470
In fact, if we do,
what will end up

127
00:06:00,470 --> 00:06:03,980
happening is we'll just end up
with corruption in the database

128
00:06:03,980 --> 00:06:04,910
essentially.

129
00:06:04,910 --> 00:06:07,040
Not unfixable corruption,
all we have to do

130
00:06:07,040 --> 00:06:08,850
is change the network type back.

131
00:06:08,850 --> 00:06:12,050
But you can't mix
network types that

132
00:06:12,050 --> 00:06:15,350
require a DR, which
of course, routers

133
00:06:15,350 --> 00:06:19,400
6 and 1 right now are
expecting a DR because they're

134
00:06:19,400 --> 00:06:20,840
set to broadcast.

135
00:06:20,840 --> 00:06:23,670
If we weren't sure, of
course, we could go look.

136
00:06:23,670 --> 00:06:24,800
But they are.

137
00:06:24,800 --> 00:06:27,830
If we set this side
to point-to-multipoint

138
00:06:27,830 --> 00:06:31,250
and we set our timers to
match, well, the neighborship

139
00:06:31,250 --> 00:06:34,980
will come up, but it
won't exchange databases.

140
00:06:34,980 --> 00:06:36,950
So ultimately,
we're going to have

141
00:06:36,950 --> 00:06:42,230
to set this to broadcast
to match routers 6 and 1,

142
00:06:42,230 --> 00:06:46,160
or we're going to have to
change this entire multi-access

143
00:06:46,160 --> 00:06:47,865
segment.

144
00:06:47,865 --> 00:06:49,490
So to do this, we'll
simply, of course,

145
00:06:49,490 --> 00:06:54,130
go in and configuration mode
into interface gigabit1.

146
00:06:54,130 --> 00:06:59,690
And we'll set the ip ospf
network to broadcast.

147
00:06:59,690 --> 00:07:02,360
Because of the
DR/BDR election, this

148
00:07:02,360 --> 00:07:04,410
will take just a few
seconds to come up.

149
00:07:04,410 --> 00:07:08,280
So we'll jump ahead to when
this neighborship comes online.

150
00:07:08,280 --> 00:07:10,220
So this has been long
enough now that this

151
00:07:10,220 --> 00:07:11,660
should have stabilized.

152
00:07:11,660 --> 00:07:14,510
So if we say show
ip ospf neighbor,

153
00:07:14,510 --> 00:07:18,380
we should now be up
with both 6 and 1, which

154
00:07:18,380 --> 00:07:19,820
we can see that we are.

155
00:07:19,820 --> 00:07:22,700
Our current state
with them is brother.

156
00:07:22,700 --> 00:07:26,300
So we have not been elected
as the DR or the BDR, which

157
00:07:26,300 --> 00:07:28,760
would make sense
since both of those

158
00:07:28,760 --> 00:07:31,790
were already neighbors with
each other, and one of them

159
00:07:31,790 --> 00:07:35,630
had already been elected as the
DR and the other as the BDR.

160
00:07:35,630 --> 00:07:37,790
So it would make
sense that router 7

161
00:07:37,790 --> 00:07:40,870
would become neither one.

162
00:07:40,870 --> 00:07:43,690
We can also turn terminal
monitor back on again

163
00:07:43,690 --> 00:07:45,820
just to make sure
that we don't have

164
00:07:45,820 --> 00:07:47,350
any more neighbors flapping.

165
00:07:47,350 --> 00:07:50,590
But more importantly, we can
do a show ip ospf neighbor

166
00:07:50,590 --> 00:07:53,710
and then ask to look at one of
these neighbors in particular.

167
00:07:53,710 --> 00:07:56,230
We'll just say pick on router 6.

168
00:07:56,230 --> 00:07:59,140
We can see that, in this case,
this neighbor has now been up

169
00:07:59,140 --> 00:08:02,120
for 2 minutes and 6 seconds.

170
00:08:02,120 --> 00:08:05,080
Now just based on the speed
of the console messages we

171
00:08:05,080 --> 00:08:07,780
saw coming in earlier,
we know that if it's

172
00:08:07,780 --> 00:08:11,590
been up for even more than a
few seconds, then it's stable.

173
00:08:11,590 --> 00:08:14,750
We can, of course,
verify router 1 as well.

174
00:08:14,750 --> 00:08:19,200
It should be close to that,
2 minutes and 24 seconds.

175
00:08:19,200 --> 00:08:23,570
So we can see that now not only
are both of these neighbors up

176
00:08:23,570 --> 00:08:27,840
at the same time, not back
and forth one then the other,

177
00:08:27,840 --> 00:08:29,820
but they're both
up as neighbors.

178
00:08:29,820 --> 00:08:31,860
But they're also stable.

179
00:08:31,860 --> 00:08:34,820
So in this video,
we saw an example

180
00:08:34,820 --> 00:08:40,590
of what happens if we have
mismatched OSPF network types.

181
00:08:40,590 --> 00:08:42,620
I hope this has been
informative for you,

182
00:08:42,620 --> 00:08:45,729
and I'd like to thank
you for viewing.

183
00:08:45,729 --> 00:08:49,000