WEBVTT

1
00:02.730 --> 00:06.750
So the first thing we wanna look at here is adding a way

2
00:06.750 --> 00:09.480
to detect the failure of a tunnel

3
00:09.480 --> 00:13.200
in a much quicker fashion than what would normally happen.

4
00:13.200 --> 00:14.430
If for some reason,

5
00:14.430 --> 00:17.700
this tunnel were to simply stop passing traffic,

6
00:17.700 --> 00:20.520
it's going to take the devices quite some time

7
00:20.520 --> 00:23.880
to figure this out and maybe start using the redundant

8
00:23.880 --> 00:26.580
or the backup tunnel exclusively,

9
00:26.580 --> 00:29.700
where one tunnel may be working and the other one may not.

10
00:29.700 --> 00:33.630
We wanna make sure that we stop using the bad tunnel,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

10
00:29.700 --> 00:33.630
We wanna make sure that we stop using the bad tunnel,

11
00:33.630 --> 00:37.290
the one that's malfunctioning as quick as possible.

12
00:37.290 --> 00:39.720
So the first step in doing that is going to be

13
00:39.720 --> 00:42.750
to detect that failure as quickly as possible,

14
00:42.750 --> 00:46.230
and that's what we're going to do in this demonstration

15
00:46.230 --> 00:50.160
using IP SLA and tracked objects.

16
00:50.160 --> 00:51.780
So let's go ahead and jump in

17
00:51.780 --> 00:54.780
and take a look at how we can provide that redundancy

18
00:54.780 --> 00:56.220
to our two tunnels

19
00:56.220 --> 00:59.193
that we have coming in right now on router one.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

20
01:01.410 --> 01:04.200
So let's start off by looking at the current situation here

21
01:04.200 --> 01:07.770
on router one, where we do have a little bit of redundancy.

22
01:07.770 --> 01:10.500
If we do a show IP route here,

23
01:10.500 --> 01:14.520
what we see is that we currently have two static routes

24
01:14.520 --> 01:18.990
to the 10.20.0.0/16 subnet,

25
01:18.990 --> 01:22.260
which is the entire network space, of course,

26
01:22.260 --> 01:25.800
that we're using in our AWS VPC.

27
01:25.800 --> 01:30.510
And that can be reached down both tunnel one and tunnel two.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

27
01:25.800 --> 01:30.510
And that can be reached down both tunnel one and tunnel two.

28
01:30.510 --> 01:32.700
The problem here is that

29
01:32.700 --> 01:35.850
if one of these tunnels becomes inoperative,

30
01:35.850 --> 01:39.114
the routing table is going to have to have some way

31
01:39.114 --> 01:41.490
to know that to remove the tunnel from this list,

32
01:41.490 --> 01:45.390
or it will continue to do equal cost multi pathic.

33
01:45.390 --> 01:48.090
So let's take a look at how this works

34
01:48.090 --> 01:51.570
by creating a failure in our tunnel.

35
01:51.570 --> 01:53.370
Now, before we start doing this,

36
01:53.370 --> 01:56.040
let's verify that we currently have connectivity

37
01:56.040 --> 01:58.410
from workstation one.

38
01:58.410 --> 02:03.030
So here on workstation one, let's just ping 10.20.20.32,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

38
01:58.410 --> 02:03.030
So here on workstation one, let's just ping 10.20.20.32,

39
02:03.030 --> 02:06.780
which is one of our servers over in the AWS cloud.

40
02:06.780 --> 02:10.200
And we can see here that it is currently working.

41
02:10.200 --> 02:12.780
So let's go back over to router one.

42
02:12.780 --> 02:15.420
So in order to simulate a failure here,

43
02:15.420 --> 02:19.530
we can't just shut down one of the tunnel interfaces.

44
02:19.530 --> 02:22.170
We could, but of course if we do that,

45
02:22.170 --> 02:24.150
the routing table will instantly see

46
02:24.150 --> 02:26.580
that local interface shut down

47
02:26.580 --> 02:29.070
and it will of course remove it from the routing table

48
02:29.070 --> 02:30.420
as it should.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

48
02:29.070 --> 02:30.420
as it should.

49
02:30.420 --> 02:33.090
What we want to see is what happens

50
02:33.090 --> 02:37.800
when the tunnel is still up-up as far as the status goes,

51
02:37.800 --> 02:41.910
but traffic through that tunnel suddenly starts to fail.

52
02:41.910 --> 02:44.730
For that, we're going to create an ACL

53
02:44.730 --> 02:48.090
that simply drops all the traffic on that tunnel

54
02:48.090 --> 02:51.570
and therefore use that to simulate a failure.

55
02:51.570 --> 02:54.450
So we'll simply go into configuration mode.

56
02:54.450 --> 02:57.490
We'll simply make a standard ACL,

57
02:57.490 --> 03:02.310
we'll just call it ACL drop and we'll simply add a deny any.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

57
02:57.490 --> 03:02.310
we'll just call it ACL drop and we'll simply add a deny any.

58
03:02.310 --> 03:04.230
Now let's go to our tunnel.

59
03:04.230 --> 03:05.160
Now we don't really know

60
03:05.160 --> 03:09.000
which tunnel is currently being used for this ping traffic

61
03:09.000 --> 03:11.880
because it will do equal cost multipathing.

62
03:11.880 --> 03:15.090
So let's just go to interface tunnel one.

63
03:15.090 --> 03:17.280
We'll apply it here first.

64
03:17.280 --> 03:20.790
We'll apply it inbound because otherwise the ACL won't deny

65
03:20.790 --> 03:22.800
outbound traffic from the router.

66
03:22.800 --> 03:24.180
So let's just do it inbound.

67
03:24.180 --> 03:26.400
It doesn't really matter which direction we block it,

68
03:26.400 --> 03:29.640
but this will be a little more extreme, so to speak.

69
03:29.640 --> 03:31.710
Now let's go back to our workstation
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

69
03:29.640 --> 03:31.710
Now let's go back to our workstation

70
03:31.710 --> 03:34.140
and see if the ping is still working.

71
03:34.140 --> 03:36.510
We can see here the ping is still working.

72
03:36.510 --> 03:39.480
So that means what we really need to do is apply this ACL

73
03:39.480 --> 03:40.890
to tunnel two.

74
03:40.890 --> 03:43.110
So, let's go back over to router one.

75
03:43.110 --> 03:45.090
We don't wanna break both tunnels,

76
03:45.090 --> 03:48.360
so let's start by taking it off of this tunnel.

77
03:48.360 --> 03:50.280
We'll go into tunnel two

78
03:50.280 --> 03:53.130
and apply the access group here.

79
03:53.130 --> 03:55.830
Let's again verify our workstation.

80
03:55.830 --> 03:57.610
We see that now the ping is failing

81
03:58.590 --> 04:00.600
and this is of course the problem.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

81
03:58.590 --> 04:00.600
and this is of course the problem.

82
04:00.600 --> 04:04.410
We have a tunnel that the router thinks is up and working,

83
04:04.410 --> 04:06.000
but really isn't.

84
04:06.000 --> 04:08.670
This is where our IP SLA will kick in

85
04:08.670 --> 04:10.710
and we can use it to bring this tunnel

86
04:10.710 --> 04:14.700
out of the routing table when it's in fact not functioning.

87
04:14.700 --> 04:16.620
So let's jump back over to router one

88
04:16.620 --> 04:18.660
and implement that change.

89
04:18.660 --> 04:20.970
We'll just break out of our ping.

90
04:20.970 --> 04:25.970
Go over to router one, and for now, let's take this ACL off.

91
04:26.130 --> 04:28.140
We do want everything to be working properly

92
04:28.140 --> 04:30.360
when we implement this change.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

92
04:28.140 --> 04:30.360
when we implement this change.

93
04:30.360 --> 04:33.600
So the first thing we wanna do is create an SLA.

94
04:33.600 --> 04:37.050
So we'll do IP SLA and we'll just make it 100.

95
04:37.050 --> 04:40.320
For the SLA, we'll do an ICMP echo.

96
04:40.320 --> 04:43.500
We're going to want it to echo the other side of the tunnel,

97
04:43.500 --> 04:47.403
which in our example is 169.254.11.1.

98
04:48.750 --> 04:51.360
We're gonna use this one for tunnel one.

99
04:51.360 --> 04:55.320
We'll set the source interface two tunnel one,

100
04:55.320 --> 04:57.990
we'll set the timeout to a thousand.

101
04:57.990 --> 05:01.050
We'll set the threshold to 1000 as well,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

101
04:57.990 --> 05:01.050
We'll set the threshold to 1000 as well,

102
05:01.050 --> 05:03.720
and we'll set the frequency to five seconds.

103
05:03.720 --> 05:07.770
What these settings will do is ping every five seconds

104
05:07.770 --> 05:11.970
and wait for one second for the timeout.

105
05:11.970 --> 05:14.670
So now what we want to do is start this SLA,

106
05:14.670 --> 05:19.670
so that's IP SLA schedule 100,

107
05:20.400 --> 05:23.400
life forever starting right now.

108
05:23.400 --> 05:27.450
Then let's do the exact same thing for tunnel two.

109
05:27.450 --> 05:29.100
I already have this configuration written,

110
05:29.100 --> 05:32.460
the only thing that changes is the SLA number
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

110
05:29.100 --> 05:32.460
the only thing that changes is the SLA number

111
05:32.460 --> 05:35.700
and the destination as well as the source interface.

112
05:35.700 --> 05:37.890
So we'll just paste the configuration in

113
05:37.890 --> 05:39.630
and we'll have that one set to start now

114
05:39.630 --> 05:41.700
and run forever as well.

115
05:41.700 --> 05:45.780
If we do a show IP SLA statistics, we can see here

116
05:45.780 --> 05:47.580
that both of these are up and running.

117
05:47.580 --> 05:49.470
The one of course we started first

118
05:49.470 --> 05:53.760
has seven successes currently, and the other one has two.

119
05:53.760 --> 05:56.970
The next thing we're going to need is a tracked object

120
05:56.970 --> 05:58.560
to watch these.

121
05:58.560 --> 06:01.057
So we will simply say first track 100,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

121
05:58.560 --> 06:01.057
So we will simply say first track 100,

122
06:02.191 --> 06:05.500
we'll track IP SLA 100 reachability.

123
06:08.160 --> 06:11.490
We're gonna wanna do the same thing for 200.

124
06:11.490 --> 06:13.080
We do a show track.

125
06:13.080 --> 06:16.890
We can see that the reachability of both of these is up.

126
06:16.890 --> 06:18.300
Now the next thing we're gonna want to do

127
06:18.300 --> 06:20.070
is change our routes.

128
06:20.070 --> 06:22.770
So if we do a show run and look at the section four routes,

129
06:22.770 --> 06:25.380
we see that we currently have these two routes

130
06:25.380 --> 06:28.800
statically configured, pointing out each tunnel.

131
06:28.800 --> 06:32.790
Now what we want to do is add a dependency
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

131
06:28.800 --> 06:32.790
Now what we want to do is add a dependency

132
06:32.790 --> 06:36.330
for the tracked objects to these static routes.

133
06:36.330 --> 06:40.470
We can do this simply by putting these routes back in

134
06:40.470 --> 06:43.770
and adding the tracked object to them.

135
06:43.770 --> 06:46.380
But an interesting note about doing this,

136
06:46.380 --> 06:48.600
if we put this configuration in,

137
06:48.600 --> 06:51.210
which is simply adding those routes again

138
06:51.210 --> 06:53.490
with the tracked object,

139
06:53.490 --> 06:56.310
and then we do our show run again,

140
06:56.310 --> 06:59.850
notice that we now have both sets of routes.

141
06:59.850 --> 07:02.250
So we do have to be careful here.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

141
06:59.850 --> 07:02.250
So we do have to be careful here.

142
07:02.250 --> 07:04.260
We're going to have to take out the routes

143
07:04.260 --> 07:08.100
that are not dependent on the tracked object.

144
07:08.100 --> 07:10.800
Otherwise, when the tracked object goes down,

145
07:10.800 --> 07:13.770
they won't be removed from the routing table.

146
07:13.770 --> 07:16.710
So we'll go ahead and take out the regular routes,

147
07:16.710 --> 07:18.360
and then we wanna make sure

148
07:18.360 --> 07:21.840
that our tracked object routes are of course still in there

149
07:21.840 --> 07:23.760
and we can see that they are.

150
07:23.760 --> 07:26.730
So if we say do show IP route,

151
07:26.730 --> 07:28.560
and we can see that both of our routes here

152
07:28.560 --> 07:30.240
are still in place.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

152
07:28.560 --> 07:30.240
are still in place.

153
07:30.240 --> 07:34.110
If we go back to our workstation, it should be working.

154
07:34.110 --> 07:37.110
We can see the ping is currently successful.

155
07:37.110 --> 07:42.110
If we put our ACL, back on interface tunnel two,

156
07:42.180 --> 07:46.920
we go back over to the workstation, temporarily down.

157
07:46.920 --> 07:50.940
Let's go back over to router one. Let's do a show track.

158
07:50.940 --> 07:53.760
We see that our tracked object is down.

159
07:53.760 --> 07:55.740
If we do our show IP route,

160
07:55.740 --> 07:58.863
we see that we now only have the route down tunnel one.

161
07:59.880 --> 08:04.080
If we were to bring it back up by taking the ACL off,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

161
07:59.880 --> 08:04.080
If we were to bring it back up by taking the ACL off,

162
08:04.080 --> 08:06.690
the tracked object will come back up

163
08:06.690 --> 08:08.670
and if we do our show IP route again,

164
08:08.670 --> 08:11.700
we see that we now have our duplicate tunnels

165
08:11.700 --> 08:13.620
back up and working.

166
08:13.620 --> 08:16.530
Also, if we check workstation one again,

167
08:16.530 --> 08:20.013
we'll see that the pings have once again started to work.

168
08:20.970 --> 08:23.460
So in this video, we took a look at

169
08:23.460 --> 08:26.550
how to add some redundancy to our tunnels

170
08:26.550 --> 08:29.160
simply by having them detect the failure

171
08:29.160 --> 08:34.160
faster than they would without IP SLA and tracked objects.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

171
08:29.160 --> 08:34.160
faster than they would without IP SLA and tracked objects.

172
08:34.500 --> 08:36.480
Another good way to add some redundancy

173
08:36.480 --> 08:39.060
is to use a dynamic routing protocol,

174
08:39.060 --> 08:41.210
and that's what we're gonna check out next.