WEBVTT

1
00:00.000 --> 00:05.040
Well next up is forming GRE tunnels and so the topology we're going to use for

2
00:05.040 --> 00:10.000
this is going to involve routers 3 and 4 and they're going to hop through

3
00:10.000 --> 00:10.680
routers

4
00:10.680 --> 00:17.440
1 and 2 down here we'll call this the underlay and we're going to form this

5
00:17.440 --> 00:21.720
tunnel connection between the two routers and we've got some subnets back

6
00:21.720 --> 00:27.520
here and the idea is that we are going to want to form an EIGRP relationship

7
00:27.520 --> 00:35.200
across this tunnel so this will be some amount of EIGRP happening. So from a
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

7
00:27.520 --> 00:35.200
across this tunnel so this will be some amount of EIGRP happening. So from a

8
00:35.200 --> 00:42.520
subnet perspective we are going to see that we've got a 10.0.13.0 all these are

9
00:42.520 --> 00:53.440
/24, 10.0.24.0.4 for router 4.3 for router 3 and we're going to use these as

10
00:53.440 --> 00:57.920
our tunnel source and destination interfaces so we're going to communicate

11
00:57.920 --> 01:02.800
through this physical underlay network and form a logical tunnel connection and
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

11
00:57.920 --> 01:02.800
through this physical underlay network and form a logical tunnel connection and

12
01:02.800 --> 01:10.600
this tunnel is going to be 10.0.34.0 with again .3 and .4 on the tunnel

13
01:10.600 --> 01:15.480
interface. So the way we form GRE tunnels is truly by forming a tunnel

14
01:15.480 --> 01:16.200
interface it's

15
01:16.200 --> 01:19.360
sort of like creating a loop back I can just create whatever tunnel interfaces

16
01:19.360 --> 01:19.480
I

17
01:19.480 --> 01:23.720
want and then I have to tell the tunnel how to actually form connections. So

18
01:23.720 --> 01:29.320
let's go ahead and do that here. I'm going to start on router 3 and on router

19
01:29.320 --> 01:35.440
3 do a config T and get onto a tunnel interface. So I can just do T0 I can type
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

19
01:29.320 --> 01:35.440
3 do a config T and get onto a tunnel interface. So I can just do T0 I can type

20
01:35.440 --> 01:40.560
tunnel if I want to I can pick a number depending on the platform. We've got

21
01:40.560 --> 01:40.760
some

22
01:40.760 --> 01:45.320
very high quantities of numbers here as options. I'm just going to be boring

23
01:45.320 --> 01:45.520
and

24
01:45.520 --> 01:50.040
choose interface tunnel 0 and then from here I can apply an IP address just

25
01:50.040 --> 01:50.160
like

26
01:50.160 --> 01:56.720
I would any other interface. So this is again 10.0.34.3 and we said that is a

27
01:56.720 --> 02:02.070
/24. But at this point the tunnel has to know how to connect and so I'm going
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

27
01:56.720 --> 02:02.070
/24. But at this point the tunnel has to know how to connect and so I'm going

28
02:02.070 --> 02:02.200
to

29
02:02.200 --> 02:06.400
say tunnel source to specify how I'm going to source this traffic. I do a

30
02:06.400 --> 02:09.760
question mark we'll see that I can specify an IP address right up here at

31
02:09.760 --> 02:13.640
the top which is how I usually like to do it. It feels a lot more intentional

32
02:13.640 --> 02:13.760
to

33
02:13.760 --> 02:17.600
choose the IP address because that way I can make sure it matches the

34
02:17.600 --> 02:18.320
destination

35
02:18.320 --> 02:22.320
of the remote tunnel. But we can also specify a physical interface here I could

36
02:22.320 --> 02:29.960
do gigabit 1/0 is that interface but I am just going to specify 10.0.13.3 as

37
02:29.960 --> 02:30.320
the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

37
02:29.960 --> 02:30.320
the

38
02:30.320 --> 02:34.870
source and for the destination it has to be an IP address because I can't

39
02:34.870 --> 02:35.200
specify

40
02:35.200 --> 02:43.040
the interface of the remote device so that would be 10.0.24.4. So from here I'm

41
02:43.040 --> 02:49.520
going to just make sure that I can ping the tunnel destination from my source

42
02:49.520 --> 02:50.000
which I

43
02:50.000 --> 02:55.360
specified is 10.0.13.3. All right good. So I can ping from this interface on

44
02:55.360 --> 02:55.520
the

45
02:55.520 --> 02:59.280
left to this interface on the right from a physical perspective. Probably

46
02:59.280 --> 02:59.440
should

47
02:59.440 --> 03:04.160
have checked that earlier but hey now we know for sure that it's going to work.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

47
02:59.440 --> 03:04.160
have checked that earlier but hey now we know for sure that it's going to work.

48
03:04.160 --> 03:10.400
But if I do a show interface tunnel 0 here it's showing up and up right now

49
03:10.400 --> 03:15.350
it's probably going to switch over to up down. The tunnel interface is like to

50
03:15.350 --> 03:15.440
be

51
03:15.440 --> 03:21.520
optimistic and when we first configure them it tries to be in an upstate and

52
03:21.520 --> 03:25.520
the reality is that it will eventually realize that the other side is not

53
03:25.520 --> 03:30.320
configured. So let's go and configure the other side router 4 here interface t0
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

53
03:25.520 --> 03:30.320
configured. So let's go and configure the other side router 4 here interface t0

54
03:30.320 --> 03:39.920
again IP address 10.0.34.4/24. And this is where I can specify

55
03:39.920 --> 03:45.120
tunnel source again I'll just do the IP address. That's how I prefer to do it.

56
03:45.120 --> 03:51.920
And then tunnel destination 13.3. And that should be it. And here we go tunnel

57
03:51.920 --> 03:52.160
is

58
03:52.160 --> 03:57.520
changed to up and so show interface tunnel 0. This is showing up let's go

59
03:57.520 --> 04:00.880
over to router 3 here looks like router 3 never actually took the tunnel
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

59
03:57.520 --> 04:00.880
over to router 3 here looks like router 3 never actually took the tunnel

60
04:00.880 --> 04:01.520
interface

61
04:01.520 --> 04:05.960
down so that's not a bad thing. Let's see if we can ping across the tunnel. So

62
04:05.960 --> 04:06.000
I

63
04:06.000 --> 04:10.960
should be able to ping 34.4 because that is a directly connected route and I

64
04:10.960 --> 04:11.760
can.

65
04:11.760 --> 04:16.480
What do I mean by directly connected route? Well again router 3 and router 4

66
04:16.480 --> 04:20.800
are not directly adjacent and I'm not running a routing protocol that's

67
04:20.800 --> 04:26.000
advertising this tunnel subnet. So I can't just ping router 4 because it's

68
04:26.000 --> 04:31.040
directly connected and yet I can because it's air quotes directly connected it
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

68
04:26.000 --> 04:31.040
directly connected and yet I can because it's air quotes directly connected it

69
04:31.040 --> 04:31.120
's

70
04:31.120 --> 04:35.760
directly connected via the tunnel subnet. If I do a show IP route here we will

71
04:35.760 --> 04:41.280
see that the tunnel subnet dot 34 right here is now a directly connected

72
04:41.280 --> 04:46.080
route on both sides. And so we have formed this tunnel and the way that it

73
04:46.080 --> 04:46.720
works is I

74
04:46.720 --> 04:52.320
send my encapsulated traffic into the underlay router 1 and router 2 are going

75
04:52.320 --> 04:52.720
to see the

76
04:52.720 --> 05:00.000
destination of 10 0 24 dot 4 not caring that I'm trying to send it to 34 dot 4.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

76
04:52.720 --> 05:00.000
destination of 10 0 24 dot 4 not caring that I'm trying to send it to 34 dot 4.

77
05:00.000 --> 05:04.640
And so they see 24 dot 4 they know how to get to 24 dot 4 because we're running

78
05:04.640 --> 05:09.040
OSPF on those routers and it eventually lands on router 4

79
05:09.040 --> 05:14.640
encapsulates it see it's destined for its tunnel interface. So that is exactly

80
05:14.640 --> 05:15.200
how

81
05:15.200 --> 05:20.640
tunneling is configured and how we can go about doing this. So we want to also

82
05:20.640 --> 05:20.800
go

83
05:20.800 --> 05:25.680
ahead and establish routing across this. If I do a show IP

84
05:25.680 --> 05:33.120
eigrp neighbor on router 3 I do see a connection that would actually be router
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

84
05:25.680 --> 05:33.120
eigrp neighbor on router 3 I do see a connection that would actually be router

85
05:33.120 --> 05:39.760
5 I think on the other side router 5 yes so router 5 is hanging out over here

86
05:39.760 --> 05:47.760
forming an eigrp connection here eigrp but we want eigrp to go everywhere and

87
05:47.760 --> 05:49.040
across the tunnel.

88
05:49.040 --> 05:54.640
So fortunately GRE supports that we're going to now configure eigrp to form a

89
05:54.640 --> 05:55.520
relationship

90
05:55.520 --> 06:01.120
across the tunnel. So I can get on to router eigrp and I'm running autonomous
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

90
05:55.520 --> 06:01.120
across the tunnel. So I can get on to router eigrp and I'm running autonomous

91
06:01.120 --> 06:02.160
system 10 in this

92
06:02.160 --> 06:08.640
environment and I can add that as a network statement network 10 dot 34 dot 3

93
06:08.640 --> 06:15.200
all zeros for the wildcard mask to specify only want to activate the interface

94
06:15.200 --> 06:15.520
that has

95
06:15.520 --> 06:20.000
that exact IP address on it again that's how I like to do my network statements

96
06:20.000 --> 06:21.280
for eigrp

97
06:21.280 --> 06:30.120
and then router 4 router eigrp autonomous system 10 network 10 dot 0 dot 34 dot
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

97
06:21.280 --> 06:30.120
and then router 4 router eigrp autonomous system 10 network 10 dot 0 dot 34 dot

98
06:30.120 --> 06:31.280
4 all zeros.

99
06:32.240 --> 06:37.790
So now yep very quickly eigrp is very very fast so if I do a show IP eigrp

100
06:37.790 --> 06:39.200
neighbor for

101
06:39.200 --> 06:43.180
router 4 I now see that I've got a connection going the other way that would be

102
06:43.180 --> 06:44.400
router 6 over on the

103
06:44.400 --> 06:50.380
right and then we have a neighbor across the tunnel. So very cool we are taking

104
06:50.380 --> 06:51.840
routes all the way

105
06:51.840 --> 06:57.060
over here from router 5 sharing it to router 3 across the tunnel to router 4

106
06:57.060 --> 06:58.160
and again router 1

107
06:58.160 --> 07:04.330
and router 2 are not at all aware of any of the routes being shared across that
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

107
06:58.160 --> 07:04.330
and router 2 are not at all aware of any of the routes being shared across that

108
07:04.330 --> 07:05.440
tunnel. So if I

109
07:05.440 --> 07:12.580
do a show IP route eigrp we'll see that we've got some loopbacks in here from

110
07:12.580 --> 07:14.960
router 5 and router 6

111
07:14.960 --> 07:19.460
and again physically the routing information is being shared across the under

112
07:19.460 --> 07:20.640
lay but logically

113
07:20.640 --> 07:25.000
it bypasses the underlay. So if I go over to router 1 for example I mean I'm

114
07:25.000 --> 07:26.640
not even running eigrp

115
07:26.640 --> 07:32.150
so if I do a show what was I doing to do there show yeah IP eigrp neighbor hold
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

115
07:26.640 --> 07:32.150
so if I do a show what was I doing to do there show yeah IP eigrp neighbor hold

116
07:32.150 --> 07:32.880
up there we go

117
07:32.880 --> 07:38.390
and I got nothing. So if I do a show IP route I would not expect to see the 5s

118
07:38.390 --> 07:39.440
or the 6s in there

119
07:39.440 --> 07:42.860
for those loopback addresses and indeed I don't the underlay is completely

120
07:42.860 --> 07:44.960
unaware. So at this

121
07:44.960 --> 07:49.930
point one thing to keep in mind that we had mentioned earlier if I do a show

122
07:49.930 --> 07:51.920
interface on the tunnel

123
07:51.920 --> 07:59.050
t0 here notice that the delay is set to 50 000 microseconds that is really high

124
07:59.050 --> 07:59.920
and the bandwidth is

125
07:59.920 --> 08:04.250
set to 100 kilobits per second even though we're running across the gig it's
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

125
07:59.920 --> 08:04.250
set to 100 kilobits per second even though we're running across the gig it's

126
08:04.250 --> 08:05.680
set to 100k not even

127
08:05.680 --> 08:12.900
100 megs 100k. Why are the bandwidth and delay set to being so bad? Well the

128
08:12.900 --> 08:14.080
reason for that is

129
08:14.080 --> 08:19.410
because Cisco is trying to anticipate a scenario where we do run eigrp over the

130
08:19.410 --> 08:21.040
underlay and so if

131
08:21.040 --> 08:27.400
router 3 is running eigrp to router 1 and router 4 then all of a sudden I'm

132
08:27.400 --> 08:28.960
going to be sharing

133
08:28.960 --> 08:34.410
my underlay routes via the overlay. I will be telling router 4 that hey just so
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

133
08:28.960 --> 08:34.410
my underlay routes via the overlay. I will be telling router 4 that hey just so

134
08:34.410 --> 08:35.280
you know I've got

135
08:35.280 --> 08:43.590
this great 10.0.13 subnet attached to me. Router 4 we know recursive routing

136
08:43.590 --> 08:46.160
can happen if we see

137
08:46.160 --> 08:52.800
the tunnel destination through the tunnel. We can't loop that around we have to

138
08:52.800 --> 08:54.320
see separate routes

139
08:54.320 --> 09:00.770
there and so Cisco is trying to prevent that scenario so if we were truly to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

139
08:54.320 --> 09:00.770
there and so Cisco is trying to prevent that scenario so if we were truly to

140
09:00.770 --> 09:01.920
take our routes

141
09:01.920 --> 09:06.900
here and let's just say I advertise it both ways I advertise it this way and I

142
09:06.900 --> 09:08.080
advertise it this

143
09:08.080 --> 09:12.390
way. Well at that point router 4 running eigrp both directions would have to

144
09:12.390 --> 09:14.080
decide which of those

145
09:14.080 --> 09:17.110
routes to accept. Well which ones are going to accept if it's just running the

146
09:17.110 --> 09:17.680
same routing

147
09:17.680 --> 09:22.070
protocol everywhere? Going to be the one with the best metric. The Cisco is

148
09:22.070 --> 09:23.440
trying to say hey this

149
09:23.440 --> 09:29.600
tunnel is a bad choice. We don't want to use this tunnel unless it's the only

150
09:29.600 --> 09:32.320
other path and so the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

150
09:29.600 --> 09:32.320
other path and so the

151
09:32.320 --> 09:36.590
idea here is simply that if we do have an underlay path, a path outside the

152
09:36.590 --> 09:37.600
tunnel we should always

153
09:37.600 --> 09:41.730
take that which is usually what we want to do. So we're saying hey this is a

154
09:41.730 --> 09:42.720
really bad path

155
09:42.720 --> 09:47.250
it's really bad because we have bad bandwidth and bad delay and therefore

156
09:47.250 --> 09:48.800
router 4 will continue

157
09:48.800 --> 09:53.510
to send this way even if we do accidentally advertise a route that we shouldn't

158
09:53.510 --> 09:55.200
have advertised. Clean

159
09:55.200 --> 09:59.440
up our drawing here a little bit and so that's something to keep in mind there.

160
09:59.440 --> 10:00.560
Now it's important
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

160
09:59.440 --> 10:00.560
Now it's important

161
10:00.560 --> 10:06.350
to recognize that tunnels support VRFs and they support them in two different

162
10:06.350 --> 10:07.680
ways. First of all

163
10:07.680 --> 10:12.920
I can place this tunnel into a VRF if I wanted to. Let's just showcase this

164
10:12.920 --> 10:14.800
here. So I could do a

165
10:14.800 --> 10:19.740
config T interface tunnel 0 and do my VRF forwarding command and now I could

166
10:19.740 --> 10:21.920
actually place the tunnel

167
10:21.920 --> 10:27.730
interface into a separate VRF entirely. Here's what's interesting. I might also

168
10:27.730 --> 10:28.880
have a situation

169
10:28.880 --> 10:33.970
where I place the underlay into a separate VRF and this is just a little bit of
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

169
10:28.880 --> 10:33.970
where I place the underlay into a separate VRF and this is just a little bit of

170
10:33.970 --> 10:35.760
a spoiler alert here

171
10:35.760 --> 10:39.820
exactly what we're going to do in the coming challenge. I'm going to create an

172
10:39.820 --> 10:41.280
underlay VRF

173
10:41.280 --> 10:45.520
to make sure that I don't create recursive routing. It's a great security

174
10:45.520 --> 10:47.040
mechanism for this type

175
10:47.040 --> 10:53.640
of scenario. The question is how do I tell a tunnel interface here that's part

176
10:53.640 --> 10:54.480
of one VRF,

177
10:54.480 --> 10:59.380
part of the default VRF, to use an interface that's in a completely different

178
10:59.380 --> 11:01.520
VRF? Well fortunately
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

178
10:59.380 --> 11:01.520
VRF? Well fortunately

179
11:01.520 --> 11:09.290
Cisco does actually give us a command for this and it is VRF tunnel VRF and

180
11:09.290 --> 11:10.640
then I can specify the

181
11:10.640 --> 11:16.580
VRF for forming the tunnel without changing the VRF that the tunnel belongs to.

182
11:16.580 --> 11:17.600
Now I can use both

183
11:17.600 --> 11:21.500
of these commands. I can place the tunnel into a VRF and I can tell the tunnel

184
11:21.500 --> 11:22.400
to use a completely

185
11:22.400 --> 11:27.250
different VRF for forming the tunnel. So keep this in mind as we go into the

186
11:27.250 --> 11:28.640
next lab challenge

187
11:28.640 --> 11:35.220
this is going to be very very important. Now one last thing has to do with MTU.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

187
11:28.640 --> 11:35.220
this is going to be very very important. Now one last thing has to do with MTU.

188
11:35.220 --> 11:36.160
So if I were to

189
11:36.160 --> 11:42.840
actually let's just go ahead and switch over to router 5 here. So router 5

190
11:42.840 --> 11:43.520
should be able to

191
11:43.520 --> 11:48.060
ping router 6 and indeed it can. It's going across the tunnel to be clear. So

192
11:48.060 --> 11:50.080
if I were to say let's

193
11:50.080 --> 11:57.800
ping this with an MTU of 1500. Oops. Alright so let's bring this back up

194
11:57.800 --> 11:59.200
because I accidentally

195
11:59.200 --> 12:03.320
hit control W which actually closes the window whereas if you're actually using
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

195
11:59.200 --> 12:03.320
hit control W which actually closes the window whereas if you're actually using

196
12:03.320 --> 12:04.240
an iOS device it

197
12:04.240 --> 12:11.280
deletes a word. So naturally I was saying MTU 500 or 1500 and I should have

198
12:11.280 --> 12:13.280
said size 1500

199
12:14.160 --> 12:21.240
and now we sent a ping that actually uses 1500 bytes. So here's the question.

200
12:21.240 --> 12:22.000
Did this get

201
12:22.000 --> 12:27.030
fragmented by going across the tunnel? Well the way to find that out is by

202
12:27.030 --> 12:28.320
setting the do not

203
12:28.320 --> 12:33.280
fragment bit. So I can say DF bit here and now we're getting MTU responses
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

203
12:28.320 --> 12:33.280
fragment bit. So I can say DF bit here and now we're getting MTU responses

204
12:33.280 --> 12:34.800
through ICMP saying hey

205
12:34.800 --> 12:40.480
that is too big to pass through without fragmenting. So we were fragmenting.

206
12:40.480 --> 12:41.120
These are getting

207
12:41.120 --> 12:45.530
fragmented. When we said hey don't fragment then we see the problem. If I were

208
12:45.530 --> 12:47.840
to say let's just do

209
12:47.840 --> 12:52.130
1400. Yeah it still went through no problem. So clearly there's a problem with

210
12:52.130 --> 12:53.440
sending a 1500

211
12:53.440 --> 12:59.320
byte packet across the tunnel. So the question is how do we fix this? There's a

212
12:59.320 --> 13:00.800
lot of misinformation
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

212
12:59.320 --> 13:00.800
lot of misinformation

213
13:00.800 --> 13:05.670
that exists around how to fix this. If I were to do a show interface tunnel

214
13:05.670 --> 13:06.880
zero we see that this

215
13:06.880 --> 13:12.140
tunnel interface has a really weird MTU that was generated. So I could get on

216
13:12.140 --> 13:12.800
there and get

217
13:12.800 --> 13:20.830
onto the tunnel interface and say hey I want to change this MTU. Yeah MTU and I

218
13:20.830 --> 13:21.840
'm going to call

219
13:21.840 --> 13:32.280
this I could do 1500 but what we'll find is that it needs to be 1476. Why 1476?
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

219
13:21.840 --> 13:32.280
this I could do 1500 but what we'll find is that it needs to be 1476. Why 1476?

220
13:32.280 --> 13:33.280
Well think about

221
13:33.280 --> 13:39.030
the math. We have said that GRE takes four bytes and the second IP header takes

222
13:39.030 --> 13:40.400
20 bytes. So that's

223
13:40.400 --> 13:46.970
a total of 24 additional bytes. So we have to configure for 1476 at max. So is

224
13:46.970 --> 13:48.240
that going to solve

225
13:48.240 --> 13:53.740
our problem? If I do a show interface tunnel we see yeah the MTU here is listed

226
13:53.740 --> 13:55.840
as a layer two MTU.

227
13:55.840 --> 14:01.140
It's not the layer three MTU. So show run interface tunnel zero and there's our
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

227
13:55.840 --> 14:01.140
It's not the layer three MTU. So show run interface tunnel zero and there's our

228
14:01.140 --> 14:02.720
layer three MTU. So

229
14:02.720 --> 14:07.390
pay attention to that. So now did that solve our problem? It did not. Why didn

230
14:07.390 --> 14:08.880
't it solve our problem?

231
14:08.880 --> 14:14.180
Well because this command doesn't actually prevent fragmentation. It just

232
14:14.180 --> 14:16.320
changes when fragmentation

233
14:16.320 --> 14:22.920
occurs. If we think about it getting it at the tunnel interface says that hey

234
14:22.920 --> 14:24.080
our MTU this is going

235
14:24.080 --> 14:28.630
to exceed our MTU we'd better fragment it before we send it on. If the MTU were

236
14:28.630 --> 14:30.000
1500 on the tunnel
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

236
14:28.630 --> 14:30.000
1500 on the tunnel

237
14:30.000 --> 14:33.440
the tunnel would have no problem with this. It would encapsulate it send to the

238
14:33.440 --> 14:34.640
physical interface

239
14:34.640 --> 14:40.750
at 1524 and the physical interface says oh I need to fragment it. And so it's

240
14:40.750 --> 14:41.600
just sort of an order

241
14:41.600 --> 14:46.320
of operations here and it is usually better to fragment it on a physical

242
14:46.320 --> 14:47.760
interface rather than

243
14:47.760 --> 14:53.680
on a logical tunnel interface. It's just better from a resources perspective.

244
14:53.680 --> 14:54.720
So we will get better

245
14:54.720 --> 14:58.960
performance this way but fragmentation is still occurring. So what is the

246
14:58.960 --> 15:00.240
solution? How do we
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

246
14:58.960 --> 15:00.240
solution? How do we

247
15:00.240 --> 15:05.500
prevent fragmentation? The way we do that is by actually increasing the MTU to

248
15:05.500 --> 15:07.600
1524 on the underlay.

249
15:07.600 --> 15:12.040
If we can do that and have it just pass through without fragmenting then at

250
15:12.040 --> 15:12.880
that point we're good

251
15:12.880 --> 15:17.830
to go so long as the system allows us to change the MTU on the tunnel interface

252
15:17.830 --> 15:19.280
to prevent being

253
15:19.280 --> 15:25.900
fragmented there. But just be aware that this command setting the MTU to 1476

254
15:25.900 --> 15:26.560
does nothing to

255
15:26.560 --> 15:30.940
prevent fragmentation but it does change how fragmentation occurs on the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

255
15:26.560 --> 15:30.940
prevent fragmentation but it does change how fragmentation occurs on the

256
15:30.940 --> 15:31.520
platform.