WEBVTT

1
00:00.000 --> 00:08.960
So for this challenge, we were asked to complete Tekkit 3 from our troubles

2
00:08.960 --> 00:11.560
hooting OSPF section,

3
00:11.560 --> 00:17.800
where Router 6 cannot reach Workstation 1 from its Gigabit 3 interface.

4
00:17.800 --> 00:22.820
So just as a reminder, we're talking about Router 6 here, specifically its Gig

5
00:22.820 --> 00:23.640
abit 3

6
00:23.640 --> 00:30.750
interface, being able to reach Workstation 1 up here, specifically the 10.10.10
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

6
00:23.640 --> 00:30.750
interface, being able to reach Workstation 1 up here, specifically the 10.10.10

7
00:30.750 --> 00:31.680
address.

8
00:31.680 --> 00:34.700
So let's go ahead and jump over to the command line on Router 6 and try to

9
00:34.700 --> 00:35.560
figure out what's

10
00:35.560 --> 00:38.640
going on with OSPF.

11
00:38.640 --> 00:42.080
So again, let's start off by verifying the ticket.

12
00:42.080 --> 00:46.660
So we'll do our paying of 10.10.10.10 and we'll source it this time from our

13
00:46.660 --> 00:47.120
Gigabit

14
00:47.120 --> 00:48.960
3 interface.

15
00:48.960 --> 00:51.160
We see that it's not working.

16
00:51.160 --> 00:53.600
We'll do our Show IP Interface Brief.

17
00:53.600 --> 00:58.600
We see that our Gigabit 1, our Gigabit 2, and our Gigabit 3 interfaces are all

18
00:58.600 --> 00:59.080
up

19
00:59.080 --> 01:00.080
up.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

19
00:59.080 --> 01:00.080
up.

20
01:00.080 --> 01:02.720
So it should not be an interface issue.

21
01:02.720 --> 01:07.540
If we do our Show IP OSPF interface brief, we see that all of the necessary

22
01:07.540 --> 01:08.400
interfaces

23
01:08.400 --> 01:10.800
are in fact running OSPF.

24
01:10.800 --> 01:13.480
They are in the correct area, Area 0.

25
01:13.480 --> 01:16.640
However, notice that none of them have neighbors.

26
01:16.640 --> 01:21.160
Now of course, we would only expect neighbors on Gigabit 1 and Gigabit 2.

27
01:21.160 --> 01:25.610
Gigabit 3 is facing a client and of course the loopback would never have

28
01:25.610 --> 01:26.600
neighbors.

29
01:26.600 --> 01:29.000
So let's see if we even know about the neighbors.

30
01:29.000 --> 01:31.520
Show IP OSPF neighbor.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

30
01:29.000 --> 01:31.520
Show IP OSPF neighbor.

31
01:31.520 --> 01:36.160
So we're not accepting the hellos from that neighbor at all.

32
01:36.160 --> 01:38.680
Let's see if we even have reachability.

33
01:38.680 --> 01:44.030
We'll ping our multicast address and we see we are in fact getting responses

34
01:44.030 --> 01:44.720
from routers

35
01:44.720 --> 01:46.000
3 and 4.

36
01:46.000 --> 01:47.320
So the interfaces are up.

37
01:47.320 --> 01:52.480
The interfaces are functional, routers 3 and 4 are in fact running OSPF.

38
01:52.480 --> 01:56.020
It doesn't necessarily mean they're configured correctly, but they're at least

39
01:56.020 --> 01:57.320
running OSPF.

40
01:57.320 --> 01:59.400
So let's go to our debugs.

41
01:59.400 --> 02:02.200
We'll debug IP OSPF packet.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

41
01:59.400 --> 02:02.200
We'll debug IP OSPF packet.

42
02:02.200 --> 02:05.520
One thing we see for sure is they're coming in a heck of a lot faster.

43
02:05.520 --> 02:09.600
Notice that almost all of these are in.

44
02:09.600 --> 02:14.190
We see a couple out pop in right there, but it's sort of interesting that the

45
02:14.190 --> 02:14.760
ins are

46
02:14.760 --> 02:19.960
coming in very quickly, but the outs, well, not so much.

47
02:19.960 --> 02:25.560
That sort of automatically makes me start thinking about timers because inbound

48
02:25.560 --> 02:26.240
packets

49
02:26.240 --> 02:29.680
are coming in a heck of a lot faster than outbound.

50
02:29.680 --> 02:33.440
So let's try our debug IP OSPF adjacencies.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

50
02:29.680 --> 02:33.440
So let's try our debug IP OSPF adjacencies.

51
02:33.440 --> 02:37.550
Now one thing to let you know, if it's a timer issue, it's actually not going

52
02:37.550 --> 02:37.960
to show

53
02:37.960 --> 02:40.120
up here on adjacencies.

54
02:40.120 --> 02:42.360
It's going to show up on hellos.

55
02:42.360 --> 02:46.000
So you can see here we're not really getting anything from adjacency.

56
02:46.000 --> 02:50.840
Let's just again go ahead and turn that off and let's debug hellos.

57
02:50.840 --> 02:56.210
So debug IP OSPF hello, we'll go ahead and turn that off pretty much right away

58
02:56.210 --> 02:56.280
.

59
02:56.280 --> 03:01.800
We're already seeing the error messages, mismatched hello parameters from and
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

59
02:56.280 --> 03:01.800
We're already seeing the error messages, mismatched hello parameters from and

60
03:01.800 --> 03:02.600
we of course have

61
03:02.600 --> 03:07.390
a message from router three and a message from router four, both saying the

62
03:07.390 --> 03:08.240
same thing.

63
03:08.240 --> 03:12.530
And what's really cool about the output of this debug, notice it's literally

64
03:12.530 --> 03:13.080
telling

65
03:13.080 --> 03:19.200
us right here what the problem is and quite frankly, how to fix it because look

66
03:19.200 --> 03:19.840
at this

67
03:19.840 --> 03:21.720
very last statement.

68
03:21.720 --> 03:28.400
It says dead received for configured for 40.

69
03:28.400 --> 03:33.790
So right there you can see that that's wrong and then the hello received one
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

69
03:28.400 --> 03:33.790
So right there you can see that that's wrong and then the hello received one

70
03:33.790 --> 03:34.360
configured

71
03:34.360 --> 03:35.920
10.

72
03:35.920 --> 03:40.240
Now this matches up to what we already saw on our debug doesn't it?

73
03:40.240 --> 03:47.030
We saw that we were receiving hellos inbound quite a bit, probably about once

74
03:47.030 --> 03:48.320
every second.

75
03:48.320 --> 03:52.800
But we were only configured to send hellos every 10 seconds.

76
03:52.800 --> 03:56.520
Now we could of course go back and look at the debug for more detail, look at

77
03:56.520 --> 03:56.920
timers

78
03:56.920 --> 03:57.920
and all that.

79
03:57.920 --> 04:02.900
I don't necessarily think that's necessary, but we certainly could if we wanted
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

79
03:57.920 --> 04:02.900
I don't necessarily think that's necessary, but we certainly could if we wanted

80
04:02.900 --> 04:03.320
to.

81
04:03.320 --> 04:05.920
It's telling us right here what the problem is.

82
04:05.920 --> 04:11.120
Now we could go through the rest of our debugging like we've done previously or

83
04:11.120 --> 04:11.560
we can just

84
04:11.560 --> 04:16.320
go ahead and test this and see if this is actually the issue.

85
04:16.320 --> 04:18.320
So let's just go into configuration mode.

86
04:18.320 --> 04:21.550
We can use the interface range command for this because we're going to be

87
04:21.550 --> 04:22.600
changing gigabit

88
04:22.600 --> 04:24.040
one and two.

89
04:24.040 --> 04:28.720
And what we need to do is set the IPOS PF hello and dead timers.

90
04:28.720 --> 04:36.120
So IPOS PF hello one and we'll set the dead to four.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

90
04:28.720 --> 04:36.120
So IPOS PF hello one and we'll set the dead to four.

91
04:36.120 --> 04:39.640
By the way, just a quick note on the output here.

92
04:39.640 --> 04:43.600
Notice that I typed IPOS PF hello one.

93
04:43.600 --> 04:45.240
I hit enter.

94
04:45.240 --> 04:51.000
I then hit the up arrow and started backing up to then type dead four.

95
04:51.000 --> 04:56.080
But notice what happened before I even typed IPOS PF dead four.

96
04:56.080 --> 04:59.440
And neighbor adjacencies already came up.

97
04:59.440 --> 05:01.040
Why am I pointing this out?
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

97
04:59.440 --> 05:01.040
Why am I pointing this out?

98
05:01.040 --> 05:05.560
Honestly, all documentation I've ever seen for OSPF says that the hello and

99
05:05.560 --> 05:06.640
dead timers

100
05:06.640 --> 05:07.960
need to match.

101
05:07.960 --> 05:11.970
However, if you look at the actual evidence here, it appears that at least on

102
05:11.970 --> 05:12.560
the Cisco

103
05:12.560 --> 05:15.960
iOS, it only checks the hello timer.

104
05:15.960 --> 05:20.360
So as soon as the hello timer matched on both sides, the neighborship came up.

105
05:20.360 --> 05:24.250
But remember, the reason these timers have to match is to prevent neighbors

106
05:24.250 --> 05:25.240
from flapping.

107
05:25.240 --> 05:29.080
So as long as the dead timers high enough, it's not going to care if it's way

108
05:29.080 --> 05:29.800
high, like

109
05:29.800 --> 05:31.440
40 seconds.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

109
05:29.800 --> 05:31.440
40 seconds.

110
05:31.440 --> 05:36.550
So again, it's making sure that the dead timer is at least four times the hello

111
05:36.550 --> 05:36.640
.

112
05:36.640 --> 05:42.160
But beyond that, iOS doesn't really seem to care how high the dead actually is.

113
05:42.160 --> 05:44.360
It doesn't have to match the other side.

114
05:44.360 --> 05:48.160
It just has to be at least four times the other side.

115
05:48.160 --> 05:52.600
So now that we think we have this fixed, let's do our show IP route for OSPF.

116
05:52.600 --> 05:55.840
And we see that now we're getting OSPF routes.

117
05:55.840 --> 05:58.920
So let's go ahead and test our original ticket.

118
05:58.920 --> 06:01.640
Remember this is source gigabit three this time.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

118
05:58.920 --> 06:01.640
Remember this is source gigabit three this time.

119
06:01.640 --> 06:03.320
And we see that it's working.

120
06:03.320 --> 06:08.880
This indicates that we have completed this challenge and therefore this skill.

121
06:08.880 --> 06:13.120
If you feel that you are missing any of the information necessary to complete

122
06:13.120 --> 06:13.960
this challenge

123
06:13.960 --> 06:18.110
successfully, I would encourage you to go back and review any necessary

124
06:18.110 --> 06:19.920
sections above.

125
06:19.920 --> 06:24.520
Otherwise, congratulations on completing troubleshooting routing protocols.

126
06:24.520 --> 06:25.840
OSPF.

127
06:25.840 --> 06:28.440
I hope this has been informative for you.

128
06:28.440 --> 06:29.960
And I'd like to thank you for viewing.

129
06:29.960 --> 06:39.960
[BLANK_AUDIO]
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

129
06:29.960 --> 06:39.960
[BLANK_AUDIO]