WEBVTT

1
00:00.000 --> 00:00.270 align:middle line:84%


2
00:00.270 --> 00:02.728 align:middle line:90%
All right, if you're ready for
another troubleshooting lab,

3
00:02.728 --> 00:04.050 align:middle line:84%
so am I. Let's begin.

4
00:04.050 --> 00:06.888 align:middle line:84%
[THEME MUSIC]

5
00:06.888 --> 00:09.260 align:middle line:84%


6
00:09.260 --> 00:13.270 align:middle line:90%
And for this lab, we have R8,
which has a loopback interface,

7
00:13.270 --> 00:15.800 align:middle line:90%
and that loopback
interface is loopback 50,

8
00:15.800 --> 00:20.240 align:middle line:90%
and it has the IP
address of 10.50.50.50.

9
00:20.240 --> 00:22.520 align:middle line:90%
And what I'd like
to do is not modify

10
00:22.520 --> 00:26.960 align:middle line:90%
the details of that loopback
50 or it's OSPF properties.

11
00:26.960 --> 00:31.550 align:middle line:90%
But at the same time, I would
love for PC7, right here,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

11
00:26.960 --> 00:31.550 align:middle line:90%
But at the same time, I would
love for PC7, right here,

12
00:31.550 --> 00:33.980 align:middle line:84%
to be able to ping 10--

13
00:33.980 --> 00:38.810 align:middle line:84%
right here, ping 10.50.50.50.

14
00:38.810 --> 00:40.770 align:middle line:90%
So our mission, should
we choose to accept it,

15
00:40.770 --> 00:42.860 align:middle line:90%
is to go ahead and
troubleshoot this

16
00:42.860 --> 00:44.720 align:middle line:90%
so that we can
leave this loopback

17
00:44.720 --> 00:46.430 align:middle line:90%
interface and its
OSPF properties

18
00:46.430 --> 00:49.385 align:middle line:90%
as it is and still have
reachability to it.

19
00:49.385 --> 00:52.010 align:middle line:90%
So there's going to be at least
one problem with authentication

20
00:52.010 --> 00:55.100 align:middle line:90%
in this lab, and also very
likely, one other problem.

21
00:55.100 --> 00:58.610 align:middle line:90%
And what I did was I
created this lab yesterday

22
00:58.610 --> 01:00.560 align:middle line:90%
along with a few other
troubleshooting labs,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

22
00:58.610 --> 01:00.560 align:middle line:90%
along with a few other
troubleshooting labs,

23
01:00.560 --> 01:02.398 align:middle line:90%
and I don't remember
all the details of all

24
01:02.398 --> 01:03.690 align:middle line:84%
the specific problems for this.

25
01:03.690 --> 01:05.232 align:middle line:90%
So it'll be a little
fun for me, too.

26
01:05.232 --> 01:07.130 align:middle line:90%
However, I would
recommend this--

27
01:07.130 --> 01:11.000 align:middle line:90%
instead of just watching me
do it from soup to dessert,

28
01:11.000 --> 01:13.430 align:middle line:90%
I would recommend
pausing it right here,

29
01:13.430 --> 01:15.392 align:middle line:90%
clicking on the link
for the Virtual Lab

30
01:15.392 --> 01:16.850 align:middle line:90%
if you're logged
on from a computer

31
01:16.850 --> 01:19.550 align:middle line:90%
to the CBT Nuggets website,
and give it a shot.

32
01:19.550 --> 01:20.820 align:middle line:84%
Get that hands-on practice.

33
01:20.820 --> 01:22.880 align:middle line:90%
Then when you're ready to
compare notes and watch

34
01:22.880 --> 01:25.420 align:middle line:90%
me do the walkthrough, then
you can go ahead and resume me.

35
01:25.420 --> 01:27.050 align:middle line:90%
So I'm going to give you a
moment right now to go ahead

36
01:27.050 --> 01:29.240 align:middle line:90%
and pause, and in a
moment we'll go back,

37
01:29.240 --> 01:30.740 align:middle line:90%
and we'll walk
through the solution.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

37
01:29.240 --> 01:30.740 align:middle line:90%
and we'll walk
through the solution.

38
01:30.740 --> 01:35.732 align:middle line:84%


39
01:35.732 --> 01:37.190 align:middle line:90%
And so here's what
I propose we do.

40
01:37.190 --> 01:39.930 align:middle line:90%
Let's just go to R7 and see
whether or not we have a route

41
01:39.930 --> 01:43.650 align:middle line:90%
to 10.50.50.50, and
let's start from there.

42
01:43.650 --> 01:46.110 align:middle line:90%
And then we'll identify
where, in the network,

43
01:46.110 --> 01:47.630 align:middle line:84%
that route is showing up.

44
01:47.630 --> 01:50.160 align:middle line:90%
Then we can backtrack
from there if we need to.

45
01:50.160 --> 01:52.930 align:middle line:90%
So here in the topology,
we'll go to R7,

46
01:52.930 --> 01:56.863 align:middle line:90%
and we'll do a show IP
route, OSPF learned routes,

47
01:56.863 --> 01:58.530 align:middle line:90%
and these are going
to be sorted for us.

48
01:58.530 --> 02:00.510 align:middle line:84%
We're looking for 10.50.50.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

48
01:58.530 --> 02:00.510 align:middle line:84%
We're looking for 10.50.50.

49
02:00.510 --> 02:01.950 align:middle line:84%
I don't see it.

50
02:01.950 --> 02:05.500 align:middle line:90%
Let's go take a peek
at a backbone router,

51
02:05.500 --> 02:07.860 align:middle line:84%
and let's pick on R4.

52
02:07.860 --> 02:10.949 align:middle line:90%
So we'll go up to R4 because
it's also an area border

53
02:10.949 --> 02:12.120 align:middle line:84%
router for area 2.

54
02:12.120 --> 02:16.048 align:middle line:90%
So on R4, we'll do
a show IP OSPF--

55
02:16.048 --> 02:17.090 align:middle line:84%
a little ahead of myself.

56
02:17.090 --> 02:22.220 align:middle line:90%
Show IP route OSPF, and it
doesn't know about the 10.50

57
02:22.220 --> 02:23.260 align:middle line:84%
network.

58
02:23.260 --> 02:24.850 align:middle line:84%
And let's go talk to R8.

59
02:24.850 --> 02:25.750 align:middle line:84%
Does R8 know it?

60
02:25.750 --> 02:29.040 align:middle line:90%
Let's do a show IP
route connected.

61
02:29.040 --> 02:32.980 align:middle line:84%
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

61
02:29.040 --> 02:32.980 align:middle line:84%


62
02:32.980 --> 02:33.490 align:middle line:84%
There it is.

63
02:33.490 --> 02:35.532 align:middle line:90%
I just want make sure the
route exists somewhere.

64
02:35.532 --> 02:39.710 align:middle line:90%
So it's here, and let's do a
show IP OSPF interface brief.

65
02:39.710 --> 02:43.337 align:middle line:90%
And that says, for loopback
50, that it is in area 50.

66
02:43.337 --> 02:45.670 align:middle line:90%
So the challenge here about
having a loopback interface,

67
02:45.670 --> 02:49.090 align:middle line:90%
or any interface that's
associated with area 50,

68
02:49.090 --> 02:52.620 align:middle line:90%
is that who is the
ABR for area 50?

69
02:52.620 --> 02:54.340 align:middle line:90%
And if we go back
to the topology

70
02:54.340 --> 02:56.080 align:middle line:84%
diagram, and I bring a pen up--

71
02:56.080 --> 03:00.880 align:middle line:90%
so we've got loopback
50, which is in area 50
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

71
02:56.080 --> 03:00.880 align:middle line:90%
so we've got loopback
50, which is in area 50

72
03:00.880 --> 03:02.560 align:middle line:84%
based on the output we just did.

73
03:02.560 --> 03:05.110 align:middle line:90%
And there is no
area border router.

74
03:05.110 --> 03:06.850 align:middle line:90%
I mean, R8 is not an
area border router.

75
03:06.850 --> 03:08.980 align:middle line:90%
It's not connected
to the backbone,

76
03:08.980 --> 03:10.810 align:middle line:90%
and R6 is not connected
to the backbone.

77
03:10.810 --> 03:11.920 align:middle line:84%
R4 is.

78
03:11.920 --> 03:14.590 align:middle line:90%
So in this topology,
that network

79
03:14.590 --> 03:17.140 align:middle line:90%
is never going to be learned
by the rest of the OSPF domain

80
03:17.140 --> 03:19.100 align:middle line:90%
because it's not
following the rules.

81
03:19.100 --> 03:21.360 align:middle line:90%
So we described the solution
to this a couple videos

82
03:21.360 --> 03:23.710 align:middle line:90%
go, in the set of videos,
regarding a virtual link.

83
03:23.710 --> 03:25.960 align:middle line:90%
We'll have more coming
up and details on that,

84
03:25.960 --> 03:29.862 align:middle line:90%
but we need a virtual
link from R4 to R8.

85
03:29.862 --> 03:30.820 align:middle line:84%
And that virtual link--
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

85
03:29.862 --> 03:30.820 align:middle line:84%
And that virtual link--

86
03:30.820 --> 03:32.800 align:middle line:90%
I'll put it in a
different color here--

87
03:32.800 --> 03:35.980 align:middle line:90%
is a logical connection
between R8 and R4,

88
03:35.980 --> 03:39.175 align:middle line:90%
this virtual link, which
allows R8 to logically become

89
03:39.175 --> 03:40.050 align:middle line:84%
part of the backbone.

90
03:40.050 --> 03:41.758 align:middle line:90%
And then guess what--
it's an area border

91
03:41.758 --> 03:44.710 align:middle line:90%
router between the backbone
area and this area 50.

92
03:44.710 --> 03:49.250 align:middle line:90%
So I think, in the output, I
think I saw that it existed.

93
03:49.250 --> 03:51.830 align:middle line:90%
Let's do a few show
commands and verify that,

94
03:51.830 --> 03:53.465 align:middle line:90%
and if we do have
a virtual link,

95
03:53.465 --> 03:55.090 align:middle line:90%
there shouldn't be
a problem with this.

96
03:55.090 --> 03:57.790 align:middle line:90%
But let's go take a look and
just verify the virtual link

97
03:57.790 --> 04:00.070 align:middle line:84%
on both R4 and R8.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

97
03:57.790 --> 04:00.070 align:middle line:84%
on both R4 and R8.

98
04:00.070 --> 04:01.930 align:middle line:90%
So here on R8 with
the output of show

99
04:01.930 --> 04:04.500 align:middle line:90%
IP OSPF interface brief,
see this thing right here--

100
04:04.500 --> 04:05.467 align:middle line:84%
VL0?

101
04:05.467 --> 04:06.550 align:middle line:84%
That's for a virtual link.

102
04:06.550 --> 04:07.930 align:middle line:84%
We can also do a command.

103
04:07.930 --> 04:10.160 align:middle line:90%
And if this is brand
new, have no worries.

104
04:10.160 --> 04:12.160 align:middle line:90%
We'll take a closer look
at it in a separate set

105
04:12.160 --> 04:13.300 align:middle line:84%
of videos on virtual links.

106
04:13.300 --> 04:17.910 align:middle line:90%
But if we do a show IP
OSPF virtual link, plural,

107
04:17.910 --> 04:19.490 align:middle line:90%
it again show us
our virtual links.

108
04:19.490 --> 04:23.240 align:middle line:90%
So this is R8 with a
virtual link to 4.4.4.4.

109
04:23.240 --> 04:26.030 align:middle line:90%
So you point to the router ID,
not the actual IP address--

110
04:26.030 --> 04:27.310 align:middle line:84%
the router ID.

111
04:27.310 --> 04:29.380 align:middle line:90%
So it looks like the
configuration is correct

112
04:29.380 --> 04:33.280 align:middle line:90%
as far as the peer, 4.4.4.4,
but it says it's down.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

112
04:29.380 --> 04:33.280 align:middle line:90%
as far as the peer, 4.4.4.4,
but it says it's down.

113
04:33.280 --> 04:35.980 align:middle line:90%
And let's go ahead
and take a look at R4,

114
04:35.980 --> 04:40.780 align:middle line:90%
and we'll do a show
IP OSPF neighbors

115
04:40.780 --> 04:45.080 align:middle line:90%
and show IP OSPF
interface brief.

116
04:45.080 --> 04:48.140 align:middle line:90%
And it's got a
virtual link as well,

117
04:48.140 --> 04:51.070 align:middle line:84%
and it also says it's down.

118
04:51.070 --> 04:54.250 align:middle line:90%
So if we do a show IP
OSPF virtual links--

119
04:54.250 --> 04:57.750 align:middle line:84%


120
04:57.750 --> 04:58.860 align:middle line:84%
you know what we could do?

121
04:58.860 --> 05:00.600 align:middle line:84%
Let's do a debug.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

121
04:58.860 --> 05:00.600 align:middle line:84%
Let's do a debug.

122
05:00.600 --> 05:04.690 align:middle line:84%
Debug, debug-- degub?

123
05:04.690 --> 05:10.320 align:middle line:90%
Debug of IP OSPF adjacency,
and maybe that'll

124
05:10.320 --> 05:14.740 align:middle line:90%
give us a clue as
to what's going on.

125
05:14.740 --> 05:16.800 align:middle line:84%
So that's local to R6.

126
05:16.800 --> 05:20.370 align:middle line:84%


127
05:20.370 --> 05:22.600 align:middle line:90%
So we have these
hellos being sent out.

128
05:22.600 --> 05:24.820 align:middle line:84%
Nothing negative to report yet.

129
05:24.820 --> 05:25.690 align:middle line:84%
That looks OK.

130
05:25.690 --> 05:28.900 align:middle line:84%


131
05:28.900 --> 05:30.890 align:middle line:84%
Well, here on R4, let's do this.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

131
05:28.900 --> 05:30.890 align:middle line:84%
Well, here on R4, let's do this.

132
05:30.890 --> 05:34.900 align:middle line:90%
Let's do a show IP
OSPF and press Enter,

133
05:34.900 --> 05:38.710 align:middle line:90%
and this says that the
area has message digest

134
05:38.710 --> 05:40.570 align:middle line:84%
authentication for area 0.

135
05:40.570 --> 05:43.780 align:middle line:90%
And if we take a look at R8,
when we create a virtual link,

136
05:43.780 --> 05:47.290 align:middle line:90%
that literally-- hmm,
strong word, Keith--

137
05:47.290 --> 05:49.630 align:middle line:90%
that logically puts
that router, that

138
05:49.630 --> 05:51.940 align:middle line:90%
wasn't previously in
the backbone area,

139
05:51.940 --> 05:54.380 align:middle line:90%
in the backbone via
that virtual link.

140
05:54.380 --> 05:57.970 align:middle line:90%
So if we do a show
IP OSPF on R8,

141
05:57.970 --> 06:00.752 align:middle line:90%
it's going to show
us that it's got
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

141
05:57.970 --> 06:00.752 align:middle line:90%
it's going to show
us that it's got

142
06:00.752 --> 06:01.960 align:middle line:84%
an interface in the backbone.

143
06:01.960 --> 06:04.870 align:middle line:90%
That's the logical interface
with the virtual link,

144
06:04.870 --> 06:08.260 align:middle line:90%
and that has no
authentication, and that's

145
06:08.260 --> 06:09.940 align:middle line:84%
why we're not peering.

146
06:09.940 --> 06:15.010 align:middle line:90%
So with authentication, if
we have MD5 authentication

147
06:15.010 --> 06:18.460 align:middle line:90%
for the area, we need to tell
R8 that, hey, for area 0,

148
06:18.460 --> 06:20.047 align:middle line:84%
we're using MD5 authentication.

149
06:20.047 --> 06:21.880 align:middle line:90%
Even if we don't have
a password configured,

150
06:21.880 --> 06:23.620 align:middle line:90%
we have to agree
on the actual type.

151
06:23.620 --> 06:25.578 align:middle line:90%
So to start our
troubleshooting, let's do this.

152
06:25.578 --> 06:31.750 align:middle line:90%
Let's go to config t
router OSPF 1 and area 0,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

152
06:25.578 --> 06:31.750 align:middle line:90%
Let's go to config t
router OSPF 1 and area 0,

153
06:31.750 --> 06:34.705 align:middle line:90%
and authentication
is message digest.

154
06:34.705 --> 06:39.450 align:middle line:84%


155
06:39.450 --> 06:41.950 align:middle line:90%
And if that was
the only problem,

156
06:41.950 --> 06:46.010 align:middle line:90%
we should get an adjacency
with R4 over the virtual link.

157
06:46.010 --> 06:50.180 align:middle line:90%
However, I'm not seeing
any messages pop up,

158
06:50.180 --> 06:56.410 align:middle line:90%
so let's do a show IP
OSPF interface brief.

159
06:56.410 --> 06:57.520 align:middle line:84%
There's our virtual link.

160
06:57.520 --> 07:00.157 align:middle line:84%
It still says down.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

160
06:57.520 --> 07:00.157 align:middle line:84%
It still says down.

161
07:00.157 --> 07:01.490 align:middle line:84%
Let's keep troubleshooting then.

162
07:01.490 --> 07:04.400 align:middle line:90%
So let's go back to
R4, and I'm going

163
07:04.400 --> 07:06.820 align:middle line:84%
to turn off the debugging here.

164
07:06.820 --> 07:10.242 align:middle line:84%
Let's do a show IP OSPF.

165
07:10.242 --> 07:11.950 align:middle line:90%
Just want to verify
I got the type right.

166
07:11.950 --> 07:17.240 align:middle line:90%
So the backbone area has
message digest authentication,

167
07:17.240 --> 07:25.930 align:middle line:90%
and if we go to
R8, show IP OSPF,

168
07:25.930 --> 07:29.050 align:middle line:90%
Here it's showing area has
message digest authentication.

169
07:29.050 --> 07:33.943 align:middle line:90%
So as far as the authentication
being enabled on R8,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

169
07:29.050 --> 07:33.943 align:middle line:90%
So as far as the authentication
being enabled on R8,

170
07:33.943 --> 07:35.110 align:middle line:84%
that looks like it's solved.

171
07:35.110 --> 07:37.858 align:middle line:84%
But we're still not--

172
07:37.858 --> 07:39.400 align:middle line:90%
our virtual link
still has a problem.

173
07:39.400 --> 07:42.800 align:middle line:84%
Show IP OSPF interface brief--

174
07:42.800 --> 07:45.220 align:middle line:90%
so there it is right there,
as the virtual link still

175
07:45.220 --> 07:52.090 align:middle line:90%
says it's down, so let's do
a show IP OSPF neighbors.

176
07:52.090 --> 07:54.245 align:middle line:90%
We've got R6 as a
neighbor, and let's look

177
07:54.245 --> 07:55.120 align:middle line:84%
at the routing table.

178
07:55.120 --> 07:58.660 align:middle line:84%
Show IP route OSPF for OSPF--

179
07:58.660 --> 08:00.880 align:middle line:84%
oh, that's not good.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

179
07:58.660 --> 08:00.880 align:middle line:84%
oh, that's not good.

180
08:00.880 --> 08:02.680 align:middle line:90%
So we're learning
just a few-- so

181
08:02.680 --> 08:04.990 align:middle line:90%
that 2 right there represents--
in that second octet.

182
08:04.990 --> 08:07.880 align:middle line:90%
That represents the-- I
matched those to the area.

183
08:07.880 --> 08:12.050 align:middle line:90%
So we're not learning about
any routes outside of area 2.

184
08:12.050 --> 08:13.458 align:middle line:90%
So let's go to R6
and take a look

185
08:13.458 --> 08:15.250 align:middle line:90%
and make sure it has
a neighborship with R4

186
08:15.250 --> 08:17.290 align:middle line:90%
because it would have to have
an adjacency there that works,

187
08:17.290 --> 08:17.790 align:middle line:84%
too.

188
08:17.790 --> 08:21.490 align:middle line:90%
So let's go back
to R6, and on R6,

189
08:21.490 --> 08:26.290 align:middle line:90%
let's do a show
IP OSPF neighbors.

190
08:26.290 --> 08:29.260 align:middle line:90%
So it's not neighboring with
R4, and the question is why?

191
08:29.260 --> 08:33.420 align:middle line:90%
Let's do a show IP
OSPF interface brief,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

191
08:29.260 --> 08:33.420 align:middle line:90%
Let's do a show IP
OSPF interface brief,

192
08:33.420 --> 08:36.260 align:middle line:84%
and looking at our topology--

193
08:36.260 --> 08:38.870 align:middle line:90%
oh, I can kind of gauge
it off this third octet.

194
08:38.870 --> 08:40.230 align:middle line:84%
That's the router number.

195
08:40.230 --> 08:42.620 align:middle line:90%
So between R4 and R6,
this is the network,

196
08:42.620 --> 08:45.080 align:middle line:84%
and it's using serial 3/2.

197
08:45.080 --> 08:47.180 align:middle line:84%
And the neighbors and--

198
08:47.180 --> 08:49.410 align:middle line:90%
so the full and count
numbers are both 0.

199
08:49.410 --> 08:51.480 align:middle line:90%
That means we don't see
any other OSPF neighbors,

200
08:51.480 --> 08:53.880 align:middle line:90%
and we're not fully adjacent
with any OSPF neighbors.

201
08:53.880 --> 08:56.840 align:middle line:90%
So let's identify
why that might be.

202
08:56.840 --> 09:00.560 align:middle line:90%
Let's do a show IP OSPF
interface for serial 3/2.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

202
08:56.840 --> 09:00.560 align:middle line:90%
Let's do a show IP OSPF
interface for serial 3/2.

203
09:00.560 --> 09:04.085 align:middle line:84%


204
09:04.085 --> 09:05.460 align:middle line:90%
So right here, it
doesn't specify

205
09:05.460 --> 09:08.470 align:middle line:90%
any type of authentication
for that interface.

206
09:08.470 --> 09:14.820 align:middle line:90%
Let's do a show CDP neighbors,
and off of our 3/2 interface,

207
09:14.820 --> 09:16.740 align:middle line:84%
we have 3/1 up on R4.

208
09:16.740 --> 09:24.160 align:middle line:90%
Let's go take a look at R4 and
show IP OSPF interface brief.

209
09:24.160 --> 09:26.790 align:middle line:84%


210
09:26.790 --> 09:30.020 align:middle line:90%
So we have OSPF enabled
on that interface.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

210
09:26.790 --> 09:30.020 align:middle line:90%
So we have OSPF enabled
on that interface.

211
09:30.020 --> 09:33.120 align:middle line:90%
The network type is point
to point, which matched R6.

212
09:33.120 --> 09:40.060 align:middle line:90%
Let's do a show IP OSPF
interface for serial 3/1,

213
09:40.060 --> 09:42.467 align:middle line:90%
and this also doesn't specify
any type of authentication.

214
09:42.467 --> 09:45.050 align:middle line:90%
So I was thinking that we were
going to have an authentication

215
09:45.050 --> 09:49.670 align:middle line:90%
issue there, but what I
do see in this output is

216
09:49.670 --> 09:51.110 align:middle line:84%
passive interface.

217
09:51.110 --> 09:53.082 align:middle line:90%
So what passive interface
does, it says, hey,

218
09:53.082 --> 09:55.040 align:middle line:90%
you know that network
you're directly connected

219
09:55.040 --> 09:56.960 align:middle line:84%
to on this interface, 3/1?

220
09:56.960 --> 09:58.490 align:middle line:90%
Go ahead and include
that in OSPF,

221
09:58.490 --> 10:00.980 align:middle line:84%
but don't bother doing hellos.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

221
09:58.490 --> 10:00.980 align:middle line:84%
but don't bother doing hellos.

222
10:00.980 --> 10:02.930 align:middle line:90%
And that's what it's
literally saying there.

223
10:02.930 --> 10:06.170 align:middle line:90%
We have passive
interface for serial 3/1,

224
10:06.170 --> 10:08.220 align:middle line:90%
and that's why we're
not neighboring with R6.

225
10:08.220 --> 10:09.620 align:middle line:84%
So let's fix that.

226
10:09.620 --> 10:15.710 align:middle line:90%
Interface router OSPF
1, no passive interface

227
10:15.710 --> 10:21.230 align:middle line:90%
for serial 3/1, and we'll
just hope for a neighborship.

228
10:21.230 --> 10:23.030 align:middle line:84%
There we go-- full adjacency.

229
10:23.030 --> 10:26.480 align:middle line:90%
So now that we've corrected the
adjacency between R4 and R6,

230
10:26.480 --> 10:28.520 align:middle line:90%
and we've also corrected
the authentication

231
10:28.520 --> 10:33.980 align:middle line:90%
statement for area 0 on
R8, let's go back to R7.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

231
10:28.520 --> 10:33.980 align:middle line:90%
statement for area 0 on
R8, let's go back to R7.

232
10:33.980 --> 10:37.460 align:middle line:90%
And let's do that same command
again, show IP route OSPF,

233
10:37.460 --> 10:40.910 align:middle line:90%
and see whether or
not we have 10--

234
10:40.910 --> 10:41.630 align:middle line:84%
we don't.

235
10:41.630 --> 10:49.050 align:middle line:84%
No 10.50.50 that I see yet.

236
10:49.050 --> 10:52.170 align:middle line:90%
Well, let's go back to R4 and
see if R4 can see that route,

237
10:52.170 --> 10:54.320 align:middle line:84%
so show IP route OSPF.

238
10:54.320 --> 10:58.080 align:middle line:84%


239
10:58.080 --> 11:00.500 align:middle line:84%
It sees 10.50.50.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

239
10:58.080 --> 11:00.500 align:middle line:84%
It sees 10.50.50.

240
11:00.500 --> 11:03.530 align:middle line:90%
Let's go to R3, which
is this guy right here,

241
11:03.530 --> 11:04.700 align:middle line:84%
this area border router.

242
11:04.700 --> 11:07.840 align:middle line:84%
Let's see if he sees it.

243
11:07.840 --> 11:10.570 align:middle line:84%
So on R3, show IP route OSPF.

244
11:10.570 --> 11:13.710 align:middle line:84%


245
11:13.710 --> 11:15.928 align:middle line:84%
Oh, he sees it.

246
11:15.928 --> 11:17.220 align:middle line:84%
Well, let's go back down to R7.

247
11:17.220 --> 11:19.637 align:middle line:90%
Maybe we just didn't allow
enough time for it to converge.

248
11:19.637 --> 11:23.010 align:middle line:90%
Show IP route OSPF,
and he sees it.

249
11:23.010 --> 11:24.340 align:middle line:84%
All right, I just wasn't--

250
11:24.340 --> 11:26.300 align:middle line:90%
I was like, oh, link state,
it's going to be really fast.

251
11:26.300 --> 11:27.460 align:middle line:90%
Well, it takes a second
or two, especially

252
11:27.460 --> 11:28.350 align:middle line:84%
in a lab environment.

253
11:28.350 --> 11:31.560 align:middle line:90%
All right, so let's
verify R7 can ping it.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

253
11:28.350 --> 11:31.560 align:middle line:90%
All right, so let's
verify R7 can ping it.

254
11:31.560 --> 11:35.440 align:middle line:84%
So we'll do a ping.

255
11:35.440 --> 11:39.000 align:middle line:90%
Let me just do a show
IP route connected.

256
11:39.000 --> 11:41.850 align:middle line:90%
Let's source it from the
same network where our PC is,

257
11:41.850 --> 11:44.130 align:middle line:84%
which is the 101.7--

258
11:44.130 --> 11:45.960 align:middle line:84%
this interface right here.

259
11:45.960 --> 11:49.130 align:middle line:90%
Just going to copy that,
and we'll do a trace

260
11:49.130 --> 11:51.785 align:middle line:84%
to 10.50.50.50.

261
11:51.785 --> 11:55.300 align:middle line:90%
I'm going to source it
from that interface,

262
11:55.300 --> 11:57.122 align:middle line:84%
and that way, we have--

263
11:57.122 --> 11:58.830 align:middle line:90%
that way, we can verify
full reachability

264
11:58.830 --> 11:59.790 align:middle line:84%
in here, a full path.

265
11:59.790 --> 12:04.830 align:middle line:90%
Great, let's go to PC7 and ping
that address one more time.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

265
11:59.790 --> 12:04.830 align:middle line:90%
Great, let's go to PC7 and ping
that address one more time.

266
12:04.830 --> 12:07.550 align:middle line:90%
In fact, we can trace it,
too, right from that PC.

267
12:07.550 --> 12:09.120 align:middle line:84%
Just going to copy that command.

268
12:09.120 --> 12:13.750 align:middle line:90%
So PC7-- he's got a default
gateway pointing to R7.

269
12:13.750 --> 12:20.310 align:middle line:90%
Let's go ahead and right click,
and we are in the business.

270
12:20.310 --> 12:24.600 align:middle line:90%
So that trace, by default,
this little VM uses UDP.

271
12:24.600 --> 12:27.340 align:middle line:90%
And so that port wasn't open
on that final destination.

272
12:27.340 --> 12:31.410 align:middle line:90%
So if you want to do a dash
capital P space 1, that says,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

272
12:27.340 --> 12:31.410 align:middle line:90%
So if you want to do a dash
capital P space 1, that says,

273
12:31.410 --> 12:35.920 align:middle line:90%
I want to use Protocol 1 ICMP
instead of UDP by default.

274
12:35.920 --> 12:38.580 align:middle line:90%
So it'll give us the same
trace, except the last hop says,

275
12:38.580 --> 12:41.490 align:middle line:90%
oh, this looks like a ping
request, and can respond back.

276
12:41.490 --> 12:44.280 align:middle line:90%
And we don't get the error about
a destination port unreachable.

277
12:44.280 --> 12:46.500 align:middle line:90%
So in this troubleshooting lab,
we've had the opportunity to do

278
12:46.500 --> 12:48.630 align:middle line:90%
some hands-on practice in
troubleshooting neighbor

279
12:48.630 --> 12:50.610 align:middle line:84%
adjacencies based on--

280
12:50.610 --> 12:51.860 align:middle line:84%
what did we have between R4--

281
12:51.860 --> 12:54.360 align:middle line:90%
oh, passive interface
between R4 and R6.

282
12:54.360 --> 12:56.430 align:middle line:90%
We also had an
authentication mismatch

283
12:56.430 --> 12:59.040 align:middle line:90%
between R8, which
had a virtual link

284
12:59.040 --> 13:01.920 align:middle line:90%
and was participating
in area 0, and area 0
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

284
12:59.040 --> 13:01.920 align:middle line:90%
and was participating
in area 0, and area 0

285
13:01.920 --> 13:03.290 align:middle line:84%
had MD5 authentication.

286
13:03.290 --> 13:05.790 align:middle line:90%
So those are the two pieces we
had to solve for this network

287
13:05.790 --> 13:06.570 align:middle line:84%
to function.

288
13:06.570 --> 13:08.070 align:middle line:90%
So thanks for joining
me in this set

289
13:08.070 --> 13:09.445 align:middle line:90%
of troubleshooting
labs regarding

290
13:09.445 --> 13:11.450 align:middle line:84%
OSPF version 2 for IPv4.

291
13:11.450 --> 13:13.080 align:middle line:90%
In our next set of
videos, we're going

292
13:13.080 --> 13:15.060 align:middle line:90%
to do some troubleshooting
again, once again

293
13:15.060 --> 13:17.520 align:middle line:90%
with authentication and
issues that can come up,

294
13:17.520 --> 13:19.620 align:middle line:90%
except this time, we'll
focus on the world

295
13:19.620 --> 13:22.767 align:middle line:84%
of IPv6 and OSPF version 3.

296
13:22.767 --> 13:25.350 align:middle line:90%
So I look forward to seeing you
in that set of videos as well.

297
13:25.350 --> 13:28.020 align:middle line:90%
Meanwhile, I hope this has
been informative for you,

298
13:28.020 --> 13:31.490 align:middle line:90%
and I'd like to thank
you for viewing.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

298
13:28.020 --> 13:31.490 align:middle line:90%
and I'd like to thank
you for viewing.