WEBVTT

1
00:00.000 --> 00:08.550
So in this challenge, we're presented with the problem that we had an IP sack

2
00:08.550 --> 00:10.440
VPN configured,

3
00:10.440 --> 00:15.180
but somebody else came in was changing configuration on these devices and now

4
00:15.180 --> 00:16.280
the tunnel's not

5
00:16.280 --> 00:20.680
working and we're being tasked with fixing it.

6
00:20.680 --> 00:23.960
So let's start off by verifying that it is in fact down.

7
00:23.960 --> 00:27.000
We'll just do a show IP interface brief.

8
00:27.000 --> 00:33.000
We see that in fact, tunnel one, the status is up, but the protocol is in fact
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

8
00:27.000 --> 00:33.000
We see that in fact, tunnel one, the status is up, but the protocol is in fact

9
00:33.000 --> 00:33.440
down.

10
00:33.440 --> 00:35.880
We do a show interface, tunnel one.

11
00:35.880 --> 00:40.120
What I'm really sort of looking for here is that it has the correct tunnel

12
00:40.120 --> 00:40.860
source.

13
00:40.860 --> 00:47.620
It has the correct tunnel destination, which we can already see looks suspect.

14
00:47.620 --> 00:51.800
The destination is 10 dot 100 dot one dot two.

15
00:51.800 --> 00:52.800
That's not correct.

16
00:52.800 --> 00:55.480
This is supposed to be going to router four.

17
00:55.480 --> 00:58.480
So that's something to keep an eye on.

18
00:58.480 --> 01:02.160
Also I want to verify the protocol and the transport.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

18
00:58.480 --> 01:02.160
Also I want to verify the protocol and the transport.

19
01:02.160 --> 01:05.160
This is set to IP sack over IP.

20
01:05.160 --> 01:08.600
So this tunnel is configured as a VTI.

21
01:08.600 --> 01:15.200
This looks relatively okay, except the destination is clearly incorrect.

22
01:15.200 --> 01:18.000
So this would be our first problem.

23
01:18.000 --> 01:23.430
We can fix this very easily by going in interface tunnel one, changing our

24
01:23.430 --> 01:24.800
tunnel destination

25
01:24.800 --> 01:31.120
to 10 dot 100 dot one dot four, which is router four's loop back.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

25
01:24.800 --> 01:31.120
to 10 dot 100 dot one dot four, which is router four's loop back.

26
01:31.120 --> 01:33.080
That's what it's supposed to be.

27
01:33.080 --> 01:35.680
We do a show IP interface brief again.

28
01:35.680 --> 01:40.160
We do however see that tunnel one is still down.

29
01:40.160 --> 01:45.720
So at this point, let's try a debug crypto.

30
01:45.720 --> 01:50.840
Like version two, let's see if our Ike is actually working properly.

31
01:50.840 --> 01:55.880
We can turn off our debugging because we already see a problem right here.

32
01:55.880 --> 01:58.160
We have failed to authenticate failed failed.

33
01:58.160 --> 02:03.560
And of course, one final notify that authentication failed.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

33
01:58.160 --> 02:03.560
And of course, one final notify that authentication failed.

34
02:03.560 --> 02:08.130
Whenever we see authentication failed, it's really a good idea to check your

35
02:08.130 --> 02:08.840
pre shared

36
02:08.840 --> 02:10.240
keys.

37
02:10.240 --> 02:14.920
So let's do a show run section crypto, I could be too key.

38
02:14.920 --> 02:17.240
This will show us the key ring.

39
02:17.240 --> 02:21.530
Now looking at this, we have our peer with the correct address and we have our

40
02:21.530 --> 02:22.240
pre shared

41
02:22.240 --> 02:24.800
key, both local and remote.

42
02:24.800 --> 02:27.640
So at first glance, this appears okay.

43
02:27.640 --> 02:29.960
Let's go check router four.

44
02:29.960 --> 02:34.390
Of course, if router four is not configured correctly, then that's going to be
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

44
02:29.960 --> 02:34.390
Of course, if router four is not configured correctly, then that's going to be

45
02:34.390 --> 02:35.000
a problem.

46
02:35.000 --> 02:37.800
Now router four looks correct as well.

47
02:37.800 --> 02:42.640
And admittedly, this is going to be a very difficult problem to see.

48
02:42.640 --> 02:46.000
Let's go back over to router one and I'll show you what I mean.

49
02:46.000 --> 02:51.760
Here on router one, I'm just going to type out the pre shared key.

50
02:51.760 --> 02:54.480
That's what the pre shared key is supposed to be.

51
02:54.480 --> 02:56.560
Cisco 123.

52
02:56.560 --> 03:00.680
We did that when we configured this through the rest of this skill.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

52
02:56.560 --> 03:00.680
We did that when we configured this through the rest of this skill.

53
03:00.680 --> 03:06.840
However, it's very difficult to see here given your font.

54
03:06.840 --> 03:10.090
Now this would vary of course based on your terminal software and the font that

55
03:10.090 --> 03:10.400
you're

56
03:10.400 --> 03:11.400
using.

57
03:11.400 --> 03:17.760
However, that character right there is not a one.

58
03:17.760 --> 03:24.650
That is an L. Notice that the top of the character is flat and level where the

59
03:24.650 --> 03:25.080
one we

60
03:25.080 --> 03:32.040
just typed in has a sloped upper line.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

60
03:25.080 --> 03:32.040
just typed in has a sloped upper line.

61
03:32.040 --> 03:33.960
Now I know what you're thinking.

62
03:33.960 --> 03:35.520
That's a dirty trick.

63
03:35.520 --> 03:37.400
They look almost identical.

64
03:37.400 --> 03:38.640
Yes, they do.

65
03:38.640 --> 03:42.720
And I sort of put this in here really to prove a point.

66
03:42.720 --> 03:47.590
You don't want to trust your eyes when you're talking about your pre shared

67
03:47.590 --> 03:48.380
keys.

68
03:48.380 --> 03:52.790
If you're a doubt and you got a debug telling you that the authentication

69
03:52.790 --> 03:53.880
failed, I would

70
03:53.880 --> 03:59.060
just go ahead and put the pre shared keys in again, particularly if you know

71
03:59.060 --> 03:59.800
somebody

72
03:59.800 --> 04:03.960
else changed things and you don't know what they changed.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

72
03:59.800 --> 04:03.960
else changed things and you don't know what they changed.

73
04:03.960 --> 04:07.950
It's best just to copy and paste the pre shared keys back in as they're

74
04:07.950 --> 04:09.880
supposed to be.

75
04:09.880 --> 04:15.240
Don't rely on what you can visually see in your terminal software.

76
04:15.240 --> 04:20.640
So now that we know that's incorrect, let's go ahead and correct the problem.

77
04:20.640 --> 04:26.470
And as I just suggested, we're going to paste this in so that we know that it's

78
04:26.470 --> 04:27.360
correct.

79
04:27.360 --> 04:29.880
Let's do our show IP interface brief again.

80
04:29.880 --> 04:32.920
The tunnel is still showing as down.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

80
04:29.880 --> 04:32.920
The tunnel is still showing as down.

81
04:32.920 --> 04:35.880
We'll give it just a minute to renegotiate.

82
04:35.880 --> 04:40.000
So here we see we got a console message telling us that the tunnel is up.

83
04:40.000 --> 04:42.040
So we'll look at it again.

84
04:42.040 --> 04:43.840
Now our tunnels up.

85
04:43.840 --> 04:45.560
Everything looks good.

86
04:45.560 --> 04:51.790
Except if we do a show IP, I, G, R, P neighbor, we'll see that our neighbor is

87
04:51.790 --> 04:54.200
still not up.

88
04:54.200 --> 04:57.520
Let's see if we can actually ping across this tunnel.

89
04:57.520 --> 04:59.800
We see here that it's not working.

90
04:59.800 --> 05:06.420
So even though the tunnel thinks it's up, traffic is not actually passing
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

90
04:59.800 --> 05:06.420
So even though the tunnel thinks it's up, traffic is not actually passing

91
05:06.420 --> 05:06.960
through it.

92
05:06.960 --> 05:10.720
Now the truth is a lot of different things could cause this.

93
05:10.720 --> 05:14.880
We could have even an access list in there filtering traffic.

94
05:14.880 --> 05:19.670
But in this case, the first thing I would look for if the tunnel thinks it's up

95
05:19.670 --> 05:20.000
, but

96
05:20.000 --> 05:25.080
it's not passing traffic, I would look at encapsulation.

97
05:25.080 --> 05:28.920
Now we already look at the encapsulation here on router one back at the

98
05:28.920 --> 05:29.880
beginning and we

99
05:29.880 --> 05:32.760
saw that it's IP sec over IP.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

99
05:29.880 --> 05:32.760
saw that it's IP sec over IP.

100
05:32.760 --> 05:37.080
So at that point, I would go verify router four.

101
05:37.080 --> 05:41.400
So one router four, let's do our show interface tunnel one.

102
05:41.400 --> 05:43.720
And right here we see a problem.

103
05:43.720 --> 05:49.000
The tunnel protocol and transport is GRE over IP.

104
05:49.000 --> 05:53.920
If we do a show run interface tunnel one, we see that the tunnel mode is not

105
05:53.920 --> 05:55.040
being set

106
05:55.040 --> 05:58.320
there for it's going to the default.

107
05:58.320 --> 06:02.440
Well this is also a fairly easy fix once we find the problem.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

107
05:58.320 --> 06:02.440
Well this is also a fairly easy fix once we find the problem.

108
06:02.440 --> 06:09.000
We'll go into the tunnel and we simply say tunnel mode IP sec IPV four.

109
06:09.000 --> 06:13.230
Now usually when you change an encapsulation like this, it's going to be best

110
06:13.230 --> 06:13.760
to reset

111
06:13.760 --> 06:14.760
the tunnel.

112
06:14.760 --> 06:19.850
It's not a problem because while the tunnel is not functional right now, anyway

113
06:19.850 --> 06:19.880
.

114
06:19.880 --> 06:22.480
So I'm going to go ahead and shut the tunnel down.

115
06:22.480 --> 06:26.880
We'll give it just a moment and we'll bring the tunnel back up.

116
06:26.880 --> 06:31.440
Let's go ahead back over to router one since that's what we were doing our
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

116
06:26.880 --> 06:31.440
Let's go ahead back over to router one since that's what we were doing our

117
06:31.440 --> 06:31.560
verification.

118
06:31.560 --> 06:35.600
And what we see here on router one is it's all the tunnel go down.

119
06:35.600 --> 06:40.290
It's all the tunnel come back up and more importantly, notice this last console

120
06:40.290 --> 06:41.080
message.

121
06:41.080 --> 06:47.290
It sees EIGRP back up and the neighborhood ship is formed, which is a darn good

122
06:47.290 --> 06:48.280
indicator

123
06:48.280 --> 06:51.320
that traffic is being passed over the tunnel.

124
06:51.320 --> 06:53.880
Of course, we can do a few final steps to verify this.

125
06:53.880 --> 06:57.900
We could do our ping again, which is now successful and we could go over to

126
06:57.900 --> 07:00.320
workstation one and
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

126
06:57.900 --> 07:00.320
workstation one and

127
07:00.320 --> 07:07.030
on workstation one, we could ping 192.168.20.10, which is workstation two and

128
07:07.030 --> 07:07.880
we can see that

129
07:07.880 --> 07:09.480
this is successful.

130
07:09.480 --> 07:14.600
Therefore, we fixed our tunnel and everything is back up and running.

131
07:14.600 --> 07:19.880
So that concludes this challenge and therefore this skill.

132
07:19.880 --> 07:24.520
So congratulations on completing describing IP set connectivity.

133
07:24.520 --> 07:28.760
I hope this has been informative for you and I'd like to thank you for viewing.

134
07:28.760 --> 07:37.920
[BLANK_AUDIO]