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

2
00:00:03,952 --> 00:00:13,350

3
00:00:13,350 --> 00:00:16,410
So now let's jump
into Trouble Ticket 3.

4
00:00:16,410 --> 00:00:20,040
This, again, is OSPF Topology
3, so the same topology

5
00:00:20,040 --> 00:00:21,480
we've been working with so far.

6
00:00:21,480 --> 00:00:24,420
This is now a problem
with router 8.

7
00:00:24,420 --> 00:00:25,800
Now, if we look
over this ticket,

8
00:00:25,800 --> 00:00:28,560
this is sort of the same ticket
we just had with router 5.

9
00:00:28,560 --> 00:00:32,350
It currently has no OSPF
routes in its routing table.

10
00:00:32,350 --> 00:00:35,440
So again, clearly, we'll be
looking at router 8 here.

11
00:00:35,440 --> 00:00:38,160
Again, this is involving
its gigabit1 interface,

12
00:00:38,160 --> 00:00:41,790
and we'll probably also do
some looking at router 7

13
00:00:41,790 --> 00:00:45,120
here, depending on what we
discover the problem is.

14
00:00:45,120 --> 00:00:46,650
But again, mostly,
we'll probably

15
00:00:46,650 --> 00:00:50,160
be focusing on this section
of our network right

16
00:00:50,160 --> 00:00:52,290
here between router
7 and router 8.

17
00:00:52,290 --> 00:00:54,330
So let's start by
jumping into router 8

18
00:00:54,330 --> 00:00:57,330
and verify that there is,
in fact, something wrong

19
00:00:57,330 --> 00:01:00,740
and that it's not
getting any routes.

20
00:01:00,740 --> 00:01:02,990
So starting here on router
8, let's, of course,

21
00:01:02,990 --> 00:01:06,350
start with our show ip route
ospf since that was the ticket,

22
00:01:06,350 --> 00:01:09,390
and we see that it does,
in fact, have no routes.

23
00:01:09,390 --> 00:01:13,190
So once again, let's
verify our interfaces.

24
00:01:13,190 --> 00:01:15,490
Now here we see that
both the loopback0

25
00:01:15,490 --> 00:01:19,690
and the gigabit1 interface
are, in fact, running ospf.

26
00:01:19,690 --> 00:01:22,060
So these are the
correct interfaces.

27
00:01:22,060 --> 00:01:24,850
Although we can also see
the gigabit1 currently

28
00:01:24,850 --> 00:01:26,260
has no neighbors.

29
00:01:26,260 --> 00:01:29,300
We do a show ip ospf neighbor.

30
00:01:29,300 --> 00:01:31,880
We see that we, in fact,
don't have a neighbor.

31
00:01:31,880 --> 00:01:34,090
Well, let's then,
of course, go see

32
00:01:34,090 --> 00:01:39,530
if router 7 is configured
properly on that side.

33
00:01:39,530 --> 00:01:42,070
So let's begin by
verifying our interfaces.

34
00:01:42,070 --> 00:01:45,970
In the case of router
7, it's gigabit3 that

35
00:01:45,970 --> 00:01:48,190
goes over towards router 8.

36
00:01:48,190 --> 00:01:51,340
And we can see that is, in
fact, configured in area 0

37
00:01:51,340 --> 00:01:52,330
as it should be.

38
00:01:52,330 --> 00:01:54,670
It has the right IP
address and mask.

39
00:01:54,670 --> 00:01:56,110
It's set to point to point.

40
00:01:56,110 --> 00:01:59,710
But it's also not
showing any neighbors.

41
00:01:59,710 --> 00:02:02,760
So let's do a show
ip ospf neighbors.

42
00:02:02,760 --> 00:02:05,400
We're pretty sure that router
8 is not a neighbor here,

43
00:02:05,400 --> 00:02:06,580
and it's not.

44
00:02:06,580 --> 00:02:09,240
So let's try digging into
this a little bit deeper.

45
00:02:09,240 --> 00:02:11,550
Let's jump back over
to router 8 just

46
00:02:11,550 --> 00:02:13,560
because it doesn't
have any neighbors yet

47
00:02:13,560 --> 00:02:15,300
and do some debugging.

48
00:02:15,300 --> 00:02:18,390
Understand we could debug
on router 7 here as well.

49
00:02:18,390 --> 00:02:22,140
It'll just be easier to see
what's going on router 8.

50
00:02:22,140 --> 00:02:25,380
So first, we'll do term on so
that we can see what's going on

51
00:02:25,380 --> 00:02:28,120
since we're in an SSH session.

52
00:02:28,120 --> 00:02:31,660
And let's start with
a debug ip ospf hello.

53
00:02:31,660 --> 00:02:33,220
Since this is the
first step that

54
00:02:33,220 --> 00:02:36,160
goes on when trying to
establish an OSPF neighborship,

55
00:02:36,160 --> 00:02:39,680
let's see what's going
on with the hellos.

56
00:02:39,680 --> 00:02:41,570
We'll go ahead and
turn off the debugging

57
00:02:41,570 --> 00:02:43,730
because we can already
see what's going on.

58
00:02:43,730 --> 00:02:46,700
We see that we're getting
mismatched hello parameters

59
00:02:46,700 --> 00:02:48,000
from our neighbor.

60
00:02:48,000 --> 00:02:49,910
We see that for
the dead interval,

61
00:02:49,910 --> 00:02:52,670
we're receiving one
second, but we're

62
00:02:52,670 --> 00:02:54,650
configured for four seconds.

63
00:02:54,650 --> 00:02:59,330
On the hello, we're receiving
zero seconds, which probably

64
00:02:59,330 --> 00:03:04,500
means it's millisecond timers,
but R configured is one second.

65
00:03:04,500 --> 00:03:09,340
So if we were to look at the
details on R ospf interface,

66
00:03:09,340 --> 00:03:12,980
we, in fact, see here that
just like the debug said,

67
00:03:12,980 --> 00:03:16,270
we are configured
for one and four.

68
00:03:16,270 --> 00:03:19,340
Let's check out router 7.

69
00:03:19,340 --> 00:03:22,430
We see here on router
7, no big surprise,

70
00:03:22,430 --> 00:03:25,160
that it's set to
the hello of 250

71
00:03:25,160 --> 00:03:27,230
and the dead interval of one.

72
00:03:27,230 --> 00:03:29,240
Since these timers
have to match,

73
00:03:29,240 --> 00:03:34,180
this is why the OSPF
neighborship is not coming up.

74
00:03:34,180 --> 00:03:37,050
So now that we've discovered
that the problem is

75
00:03:37,050 --> 00:03:39,750
the timers don't
match, well, now

76
00:03:39,750 --> 00:03:42,150
we have to discuss
how to fix it.

77
00:03:42,150 --> 00:03:45,870
Now we could, of course,
just set all the timers back

78
00:03:45,870 --> 00:03:47,160
to their defaults.

79
00:03:47,160 --> 00:03:51,490
For this type of interface, that
would be 10 and 40, which now--

80
00:03:51,490 --> 00:03:53,040
that's pretty high timers.

81
00:03:53,040 --> 00:03:56,160
We generally don't want to
go with timers that slow.

82
00:03:56,160 --> 00:03:59,490
So maybe we could go
with the one and four

83
00:03:59,490 --> 00:04:01,710
like router 8 is using.

84
00:04:01,710 --> 00:04:06,810
And some routers don't support
millisecond timers for OSPF,

85
00:04:06,810 --> 00:04:10,270
so that might actually be
something we have to do.

86
00:04:10,270 --> 00:04:12,930
But in this case,
both of the routers

87
00:04:12,930 --> 00:04:15,930
do, in fact, support
millisecond hello timers,

88
00:04:15,930 --> 00:04:19,019
so the best idea
here would probably

89
00:04:19,019 --> 00:04:23,160
be to set router 8 to
match router 7 using

90
00:04:23,160 --> 00:04:28,420
250-millisecond hellos and
one-second dead interval.

91
00:04:28,420 --> 00:04:31,260
So let's go ahead and
go with that solution.

92
00:04:31,260 --> 00:04:34,560
That, of course, means we have
to go back over to router 8.

93
00:04:34,560 --> 00:04:39,580
We'll go into configuration
mode, interface gigabit1.

94
00:04:39,580 --> 00:04:42,430
The way we configure the
millisecond timers is we

95
00:04:42,430 --> 00:04:44,650
actually have to configure
the dead interval,

96
00:04:44,650 --> 00:04:47,860
and we use the option
here called minimal.

97
00:04:47,860 --> 00:04:51,610
If we try to set it
to one second, which

98
00:04:51,610 --> 00:04:54,340
is really what we're doing,
but all we can do then

99
00:04:54,340 --> 00:04:55,360
is hit Enter.

100
00:04:55,360 --> 00:04:58,630
And the problem with
this is if we take off

101
00:04:58,630 --> 00:05:00,850
dead interval for
just a minute and we

102
00:05:00,850 --> 00:05:02,770
look at the hello
interval, we see

103
00:05:02,770 --> 00:05:06,790
that there's no way to set the
millisecond timer directly.

104
00:05:06,790 --> 00:05:09,590
The lowest we can set
this is to one second.

105
00:05:09,590 --> 00:05:12,970
So what I have to do is I
have to use the dead interval,

106
00:05:12,970 --> 00:05:17,050
like we said, but we use
this other command minimal.

107
00:05:17,050 --> 00:05:20,860
Now, as we see, minimal
sets it to one second.

108
00:05:20,860 --> 00:05:23,530
Well, then, how do we
set the hello interval?

109
00:05:23,530 --> 00:05:25,990
Well, notice we can't
just hit Enter here.

110
00:05:25,990 --> 00:05:27,940
If I try, it'll
give me an error.

111
00:05:27,940 --> 00:05:30,040
It'll tell me it's
an Incomplete command

112
00:05:30,040 --> 00:05:32,200
because that's not
enough information.

113
00:05:32,200 --> 00:05:36,250
It needs-- it requires
the hello multiplier.

114
00:05:36,250 --> 00:05:38,740
This is, of course,
how many hellos

115
00:05:38,740 --> 00:05:41,830
it's going to send
in that one second.

116
00:05:41,830 --> 00:05:48,010
Remember that the goal is to get
a 250-millisecond hello timer

117
00:05:48,010 --> 00:05:50,530
with a one-second dead interval.

118
00:05:50,530 --> 00:05:53,620
Well, that's fine,
but to get that 250,

119
00:05:53,620 --> 00:05:55,120
what we have to
realize is that we

120
00:05:55,120 --> 00:05:57,430
have to take our 1,000
milliseconds that's

121
00:05:57,430 --> 00:06:01,270
in the second and
divide that by the 250

122
00:06:01,270 --> 00:06:02,890
that we want for the hellos.

123
00:06:02,890 --> 00:06:05,320
This, of course, is 4.

124
00:06:05,320 --> 00:06:07,360
So this means that
our hello multiplier

125
00:06:07,360 --> 00:06:11,770
needs to be four in order to
get a 250-millisecond hello.

126
00:06:11,770 --> 00:06:14,710
We see here that our OSPF
neighborship has already

127
00:06:14,710 --> 00:06:17,920
come back up, so this is
a pretty good indicator

128
00:06:17,920 --> 00:06:19,910
that we've done this correctly.

129
00:06:19,910 --> 00:06:23,030
Let's go ahead and look at
the interface detail again,

130
00:06:23,030 --> 00:06:25,360
and we see that our hello
and our dead intervals

131
00:06:25,360 --> 00:06:29,290
are, in fact, set to 250
with a dead interval of one.

132
00:06:29,290 --> 00:06:31,840
Now again, we did see
the neighborship come up

133
00:06:31,840 --> 00:06:33,740
in our console window there.

134
00:06:33,740 --> 00:06:37,870
However, let's do a show ip
ospf neighbor just to verify.

135
00:06:37,870 --> 00:06:39,880
We see that 7 is back up.

136
00:06:39,880 --> 00:06:43,610
And, of course, always verify
the original trouble ticket.

137
00:06:43,610 --> 00:06:47,830
So show IP route
ospf, and we see

138
00:06:47,830 --> 00:06:51,910
that we have a growing
number of OSPF routes

139
00:06:51,910 --> 00:06:54,460
in our routing table.

140
00:06:54,460 --> 00:06:57,620
As we fix more and more problems
through our environment,

141
00:06:57,620 --> 00:07:01,700
notice that our OSPF routing
table is getting larger.

142
00:07:01,700 --> 00:07:03,970
But the real
important point here

143
00:07:03,970 --> 00:07:07,210
is that we have the
routes on router 8, which

144
00:07:07,210 --> 00:07:08,960
was the original ticket.

145
00:07:08,960 --> 00:07:13,570
So, in this case, we saw an
example of OSPF neighbors

146
00:07:13,570 --> 00:07:17,800
not being able to come up if
the hello and dead timers don't

147
00:07:17,800 --> 00:07:18,880
match.

148
00:07:18,880 --> 00:07:20,980
I hope this has been
informative for you,

149
00:07:20,980 --> 00:07:24,030
and I'd like to thank
you for viewing.

150
00:07:24,030 --> 00:07:27,000