1
00:00:00,000 --> 00:00:07,970

2
00:00:07,970 --> 00:00:11,090
So now, that we've got
PHP all squared away,

3
00:00:11,090 --> 00:00:13,430
let's jump in and
take a closer look

4
00:00:13,430 --> 00:00:17,540
at TTL propagation in MPLS.

5
00:00:17,540 --> 00:00:21,440
The default behavior
for TTL propagation

6
00:00:21,440 --> 00:00:25,340
is that when the label is
imposed onto the packet,

7
00:00:25,340 --> 00:00:32,540
we take the original IP TTL and
copy that to the new label TTL.

8
00:00:32,540 --> 00:00:36,330
Now, this has some advantages
and some disadvantages.

9
00:00:36,330 --> 00:00:40,130
The advantage is
things like trace route

10
00:00:40,130 --> 00:00:43,490
and maybe some other utilities
will still work properly.

11
00:00:43,490 --> 00:00:47,390
The downside is, our
customers can actually

12
00:00:47,390 --> 00:00:49,640
see the entire core
of our network,

13
00:00:49,640 --> 00:00:52,400
and we may not
necessarily want customers

14
00:00:52,400 --> 00:00:56,250
to see all of the P routers
in the center of our network.

15
00:00:56,250 --> 00:01:00,560
So let's jump in, take a look
at what TTL propagation does

16
00:01:00,560 --> 00:01:02,510
by default, and then
of course, we'll

17
00:01:02,510 --> 00:01:05,120
take a look at how to
alter that behavior.

18
00:01:05,120 --> 00:01:07,040
And we actually have
a couple of options

19
00:01:07,040 --> 00:01:08,370
that we need to look at.

20
00:01:08,370 --> 00:01:10,430
So of course, we'll start
looking at the topology

21
00:01:10,430 --> 00:01:12,560
just as a reminder of
how everything's set up

22
00:01:12,560 --> 00:01:14,690
and the traffic flow we're
going to be examining,

23
00:01:14,690 --> 00:01:16,580
and then we'll jump
on to the command line

24
00:01:16,580 --> 00:01:21,880
and check out what TTL
propagation is all about.

25
00:01:21,880 --> 00:01:25,410
So our topology here is
really just a reminder for you

26
00:01:25,410 --> 00:01:27,250
of how everything is set up.

27
00:01:27,250 --> 00:01:28,950
We're going to start
this discussion

28
00:01:28,950 --> 00:01:32,400
by focusing on the traffic
coming from router 6,

29
00:01:32,400 --> 00:01:34,290
going to router 8.

30
00:01:34,290 --> 00:01:36,960
And again it will be
probably multipathing here

31
00:01:36,960 --> 00:01:38,820
in the middle, but
the real question

32
00:01:38,820 --> 00:01:42,690
is, will we be able to see
the path in the center,

33
00:01:42,690 --> 00:01:45,280
and that's what this
discussion is all about.

34
00:01:45,280 --> 00:01:47,460
So let's go ahead and jump
in to the command line

35
00:01:47,460 --> 00:01:51,940
and play around with
TTL propagation.

36
00:01:51,940 --> 00:01:56,260
So let's begin by looking at the
actual problem, if we actually

37
00:01:56,260 --> 00:01:57,620
want to call it a problem.

38
00:01:57,620 --> 00:02:01,930
But let's do a trace to
10.100.10.8 here on router 6.

39
00:02:01,930 --> 00:02:06,040
So again, we're tracing
to a network on router 8.

40
00:02:06,040 --> 00:02:08,380
And the big problem we
have with this output

41
00:02:08,380 --> 00:02:11,550
is specifically, that
we're seeing router 3.

42
00:02:11,550 --> 00:02:13,450
We're not really so
concerned that you

43
00:02:13,450 --> 00:02:16,870
can see router 1, because
router 6 is already

44
00:02:16,870 --> 00:02:19,390
in OSPF neighbor with
that router anyway

45
00:02:19,390 --> 00:02:21,850
and sort of the
same with router 5.

46
00:02:21,850 --> 00:02:24,850
Router 5 and router 8 are
already OSPF neighbors,

47
00:02:24,850 --> 00:02:27,250
so from the customer's
perspective,

48
00:02:27,250 --> 00:02:29,830
we're already going to
know where the PEs are,

49
00:02:29,830 --> 00:02:34,635
we're aware of the PEs, so
it's really about router 3

50
00:02:34,635 --> 00:02:37,780
here, which is a P router,
and the customer really

51
00:02:37,780 --> 00:02:39,500
shouldn't be able to see that.

52
00:02:39,500 --> 00:02:44,260
So let's go over to router
1 and turn off our MPLS TTL

53
00:02:44,260 --> 00:02:45,800
propagation.

54
00:02:45,800 --> 00:02:51,970
So the command for this
is MPLS IP TTL propagate,

55
00:02:51,970 --> 00:02:54,040
and we say disable.

56
00:02:54,040 --> 00:02:56,440
We'll commit those
changes, and we

57
00:02:56,440 --> 00:02:58,580
can exit out of configuration.

58
00:02:58,580 --> 00:03:00,970
So now, of course, let's
go back to router 6

59
00:03:00,970 --> 00:03:03,190
and see what it looks like now.

60
00:03:03,190 --> 00:03:07,570
We'll do our trace again, and
as we've already mentioned, yes,

61
00:03:07,570 --> 00:03:08,800
we still see router 1.

62
00:03:08,800 --> 00:03:10,600
Yes, we still see router 5.

63
00:03:10,600 --> 00:03:14,680
We knew about those anyway,
but we lost the P router.

64
00:03:14,680 --> 00:03:16,760
We don't see it anymore.

65
00:03:16,760 --> 00:03:19,360
And while we're doing
this trace, why don't we

66
00:03:19,360 --> 00:03:22,180
hop into Wireshark, capture
one of these packets,

67
00:03:22,180 --> 00:03:24,820
and take a look at what
it's actually doing.

68
00:03:24,820 --> 00:03:27,020
So we have our Wireshark
capture running.

69
00:03:27,020 --> 00:03:29,920
Let's go ahead and do our
trace again, and then let's

70
00:03:29,920 --> 00:03:31,930
get back over to Wireshark.

71
00:03:31,930 --> 00:03:36,910
So what we see in Wireshark is,
if we look at this UDP packet,

72
00:03:36,910 --> 00:03:43,960
going from 192.168.16.6
to the 10.100.10.8,

73
00:03:43,960 --> 00:03:48,250
which is packet 29 here, we
can actually see a few things

74
00:03:48,250 --> 00:03:49,360
of interest.

75
00:03:49,360 --> 00:03:51,970
First, notice what's going on.

76
00:03:51,970 --> 00:03:53,680
We have two labels here.

77
00:03:53,680 --> 00:03:58,390
We know that the 24.302
is the forwarding label,

78
00:03:58,390 --> 00:04:03,230
and we know that label
24.507 is the VPN label.

79
00:04:03,230 --> 00:04:07,330
And if we look at the Exp bits
right here on these packets,

80
00:04:07,330 --> 00:04:12,370
we can actually see our
QOS from our previous lab

81
00:04:12,370 --> 00:04:15,370
still in place, and
we see how it's only

82
00:04:15,370 --> 00:04:18,880
marking the Exp on
the forwarding label

83
00:04:18,880 --> 00:04:22,240
and not on the VPN label,
which of course, is

84
00:04:22,240 --> 00:04:24,850
exactly what we're expecting
from the behavior we

85
00:04:24,850 --> 00:04:27,470
saw in our previous video.

86
00:04:27,470 --> 00:04:30,430
We also see how the
S bits work here.

87
00:04:30,430 --> 00:04:32,680
We see that the S bit
on the first label

88
00:04:32,680 --> 00:04:35,950
is, of course, not set because
it's not the bottom of stack,

89
00:04:35,950 --> 00:04:40,240
and the S bit on the
VPN label is set.

90
00:04:40,240 --> 00:04:42,820
And then of course, what
we're really here to look at

91
00:04:42,820 --> 00:04:44,740
is the TTL.

92
00:04:44,740 --> 00:04:47,890
When you disable
TTL propagation,

93
00:04:47,890 --> 00:04:52,600
what the router does is it
just sets the TTL to 255.

94
00:04:52,600 --> 00:04:54,280
And since we're
capturing this right

95
00:04:54,280 --> 00:04:57,760
on router 1, which is where
we're imposing these labels,

96
00:04:57,760 --> 00:05:02,510
we see that it's right
at the value of 255.

97
00:05:02,510 --> 00:05:04,840
So this all looks like
it's working fine,

98
00:05:04,840 --> 00:05:08,120
but we do have one issue that
we probably want to look at.

99
00:05:08,120 --> 00:05:10,360
Let's go back over to router 1.

100
00:05:10,360 --> 00:05:14,320
So here on router 1, we may
have an unintended consequence

101
00:05:14,320 --> 00:05:15,940
of what we've done.

102
00:05:15,940 --> 00:05:20,080
If we were to say to trace, to
router 5's loopback, sourcing

103
00:05:20,080 --> 00:05:23,020
it from our loopback
interface, this

104
00:05:23,020 --> 00:05:26,230
appears like we're
directly hitting router 5.

105
00:05:26,230 --> 00:05:29,890
Now, I'm pretty sure if
we go back to the diagram,

106
00:05:29,890 --> 00:05:34,030
that router 1 is not directly
connected to router 5.

107
00:05:34,030 --> 00:05:38,200
We have routers 3 or 4 in
there, and it's probably, again,

108
00:05:38,200 --> 00:05:39,340
multipathing.

109
00:05:39,340 --> 00:05:41,950
We could actually tell
that from the trace,

110
00:05:41,950 --> 00:05:43,450
because it's actually
hitting router

111
00:05:43,450 --> 00:05:48,970
5 on the two different
interfaces, 35, 5 and 45, 5.

112
00:05:48,970 --> 00:05:51,880
So we can actually sort
of tell from the trace

113
00:05:51,880 --> 00:05:53,800
that it's load
sharing, but the point

114
00:05:53,800 --> 00:05:56,860
is we're not seeing
routers 3 and 4, which

115
00:05:56,860 --> 00:05:59,390
are part of our own topology.

116
00:05:59,390 --> 00:06:02,380
So as the service
provider, yes, we

117
00:06:02,380 --> 00:06:06,610
wanted to hide this MPLS
core from our customers.

118
00:06:06,610 --> 00:06:08,800
That doesn't
necessarily mean that we

119
00:06:08,800 --> 00:06:11,450
wanted to hide the
core from ourselves.

120
00:06:11,450 --> 00:06:14,350
Now, the cool thing is, we
have a real easy addition

121
00:06:14,350 --> 00:06:16,210
to this command
we can put in that

122
00:06:16,210 --> 00:06:18,130
will solve this
problem completely,

123
00:06:18,130 --> 00:06:20,650
and this is generally
how I would recommend

124
00:06:20,650 --> 00:06:23,560
running the environment.

125
00:06:23,560 --> 00:06:26,760
So we simply go back
into configuration mode,

126
00:06:26,760 --> 00:06:29,790
and we go back to the
previous command we put in

127
00:06:29,790 --> 00:06:35,670
and we simply add this one key
word to it, which is forwarded.

128
00:06:35,670 --> 00:06:41,530
This will have it not propagate
the TTL on forwarded packets,

129
00:06:41,530 --> 00:06:45,665
but if it's locally generated,
it will still do so.

130
00:06:45,665 --> 00:06:47,040
Now, you can see
you can actually

131
00:06:47,040 --> 00:06:49,240
choose the opposite
option, if you want.

132
00:06:49,240 --> 00:06:51,610
I'm not sure of a
practical use for that,

133
00:06:51,610 --> 00:06:54,030
but I'm sure there's
one out there somewhere.

134
00:06:54,030 --> 00:06:58,440
I always just do the forwarded,
we'll commit our change,

135
00:06:58,440 --> 00:07:01,420
and now, let's do
our trace again.

136
00:07:01,420 --> 00:07:02,940
If we do it a few
times, we might

137
00:07:02,940 --> 00:07:05,610
be able to see that it's
actually hitting router 4,

138
00:07:05,610 --> 00:07:08,700
so yeah, here we can see it
hits router 4 for the first hop.

139
00:07:08,700 --> 00:07:11,610
One of the downsides of
equal cost multipathing

140
00:07:11,610 --> 00:07:14,370
and the way the trace
works, the trace

141
00:07:14,370 --> 00:07:17,110
sends three copies
of every frame,

142
00:07:17,110 --> 00:07:19,980
which means it's going
path 1, path 2, path 1.

143
00:07:19,980 --> 00:07:23,190
So the next time, it's going
to do path 2, path 1, path 2.

144
00:07:23,190 --> 00:07:25,440
So it can make our
traces look a little bit

145
00:07:25,440 --> 00:07:27,240
interesting with
the multipathing,

146
00:07:27,240 --> 00:07:29,820
but the fact of the matter
is that's what it's doing,

147
00:07:29,820 --> 00:07:32,310
and here, we're seeing
routers 3 and 4.

148
00:07:32,310 --> 00:07:35,670
So we can still troubleshoot
the core of our own network.

149
00:07:35,670 --> 00:07:39,870
Yet, if we go back to the
customer, on router 6,

150
00:07:39,870 --> 00:07:44,610
and we do our same trace
again, router 6, the customer,

151
00:07:44,610 --> 00:07:46,530
still doesn't see the core.

152
00:07:46,530 --> 00:07:49,530
So ultimately, I think
this is the best solution.

153
00:07:49,530 --> 00:07:51,510
The customer doesn't
see the core,

154
00:07:51,510 --> 00:07:54,580
but those of us who work
at the service provider,

155
00:07:54,580 --> 00:07:58,080
we can still use tools
like traceroute and things

156
00:07:58,080 --> 00:08:00,480
like this to actually
be able to troubleshoot

157
00:08:00,480 --> 00:08:02,640
the center of our core.

158
00:08:02,640 --> 00:08:04,110
Now, of course,
we would want this

159
00:08:04,110 --> 00:08:07,020
to work in both directions,
and if we go over

160
00:08:07,020 --> 00:08:10,260
to router 8 right now, we'll
find out that it's not.

161
00:08:10,260 --> 00:08:16,170
If we do the trace 10.100.1.6,
notice, it's seeing router 4,

162
00:08:16,170 --> 00:08:18,640
so we can still see the
core of this direction.

163
00:08:18,640 --> 00:08:22,560
So we need to turn this
off on all of our PEs.

164
00:08:22,560 --> 00:08:26,310
Now, router 5, since it's,
of course, running iOS XE,

165
00:08:26,310 --> 00:08:28,950
is a little bit of
a different command.

166
00:08:28,950 --> 00:08:31,140
We simply go into
Configuration mode,

167
00:08:31,140 --> 00:08:36,280
and it's no MPLS
IP propagate TTL.

168
00:08:36,280 --> 00:08:40,559
And again, it has that option
to do forwarded or local,

169
00:08:40,559 --> 00:08:43,289
so of course,
we'll do forwarded.

170
00:08:43,289 --> 00:08:45,600
Now, that that's in
there, this should now

171
00:08:45,600 --> 00:08:47,080
be functional both directions.

172
00:08:47,080 --> 00:08:49,860
Let's just verify from router 8.

173
00:08:49,860 --> 00:08:53,920
Do our trace one more time, and
now, we do not see the core.

174
00:08:53,920 --> 00:08:58,040
So the core is now hidden
in both directions.

175
00:08:58,040 --> 00:09:01,150
So in this video, we
took a closer look

176
00:09:01,150 --> 00:09:05,020
at the TTL operation in MPLS.

177
00:09:05,020 --> 00:09:09,670
Remember, that the default
on both iOS XE and iOS XR

178
00:09:09,670 --> 00:09:13,630
is to take the TTL from
the original IP packet

179
00:09:13,630 --> 00:09:16,090
and put it onto the new labels.

180
00:09:16,090 --> 00:09:19,990
However, this can be
disabled, and if we do so,

181
00:09:19,990 --> 00:09:23,440
we get the benefit that the
customers can't see the core,

182
00:09:23,440 --> 00:09:26,230
but we can do it just
for forwarded traffic

183
00:09:26,230 --> 00:09:27,940
so that we can
still troubleshoot

184
00:09:27,940 --> 00:09:29,800
the core of our own network.

185
00:09:29,800 --> 00:09:33,550
Also, keep in mind that if
it doesn't propagate the TTL,

186
00:09:33,550 --> 00:09:36,950
it just flat out sets it to 255.

187
00:09:36,950 --> 00:09:39,550
So that takes care
of TTL propagation.

188
00:09:39,550 --> 00:09:42,730
Up next, we want to
look at route leaking.

189
00:09:42,730 --> 00:09:45,730
Sometimes, we might
need to get routes

190
00:09:45,730 --> 00:09:48,820
either between the
global table and a VRF

191
00:09:48,820 --> 00:09:52,180
or maybe between VRFs
of different customers.

192
00:09:52,180 --> 00:09:55,310
And that's exactly what we're
going to take a look at next.

193
00:09:55,310 --> 00:09:58,570
Until then, I hope this has
been informative for you,

194
00:09:58,570 --> 00:10:01,650
and I'd like to thank
you for viewing.

195
00:10:01,650 --> 00:10:05,000