1
00:00:00,000 --> 00:00:00,944

2
00:00:00,944 --> 00:00:04,248
[AUDIO LOGO]

3
00:00:04,248 --> 00:00:07,760

4
00:00:07,760 --> 00:00:10,920
So now let's jump in
and take a look at TTL

5
00:00:10,920 --> 00:00:14,700
security, which is another one
of our protection mechanisms

6
00:00:14,700 --> 00:00:16,560
for our neighborships.

7
00:00:16,560 --> 00:00:20,580
The main idea is we can
ensure that neighbors are not

8
00:00:20,580 --> 00:00:23,880
allowed to be more than
x number of hops away,

9
00:00:23,880 --> 00:00:26,350
and we'll, of course,
be determining that.

10
00:00:26,350 --> 00:00:28,860
But the other
thing it does is it

11
00:00:28,860 --> 00:00:32,670
allows BGP to quickly
discard packets

12
00:00:32,670 --> 00:00:34,830
that are coming
from further away

13
00:00:34,830 --> 00:00:37,690
without it having to
fully process them.

14
00:00:37,690 --> 00:00:41,220
So from that perspective,
it can also help protect us

15
00:00:41,220 --> 00:00:43,270
from denial of service attacks.

16
00:00:43,270 --> 00:00:45,840
So let's jump in and
take a look a little bit

17
00:00:45,840 --> 00:00:49,080
at how the details
of TTL security work.

18
00:00:49,080 --> 00:00:52,380
And then of course, we're going
to jump onto the command line

19
00:00:52,380 --> 00:00:55,470
and see it in action.

20
00:00:55,470 --> 00:00:59,000
So in addition to preventing
neighbors that are too many

21
00:00:59,000 --> 00:01:02,600
hops away from being able
to form a neighborship,

22
00:01:02,600 --> 00:01:09,170
TTL security can also help
protect BGP from TCP SYN flood

23
00:01:09,170 --> 00:01:12,260
attacks, and the reason
this is important

24
00:01:12,260 --> 00:01:17,510
is because even though
the default TTL on eBGP

25
00:01:17,510 --> 00:01:21,650
is, in fact, set to
1, that fact does not

26
00:01:21,650 --> 00:01:26,030
prevent an attacker, somebody
who's not necessarily

27
00:01:26,030 --> 00:01:31,670
following the rules, from
setting their TTL to 255

28
00:01:31,670 --> 00:01:36,650
and therefore allowing their BG
packets to reach us no matter

29
00:01:36,650 --> 00:01:38,600
how far away they are.

30
00:01:38,600 --> 00:01:41,670
Now, the return
traffic, of course,

31
00:01:41,670 --> 00:01:43,980
still would not be
able to get there.

32
00:01:43,980 --> 00:01:48,480
So this would not affect
the TTL on the local router.

33
00:01:48,480 --> 00:01:51,140
So again, the return
traffic wouldn't get back

34
00:01:51,140 --> 00:01:52,100
to the sender.

35
00:01:52,100 --> 00:01:55,110
We wouldn't actually form
a neighborship with them,

36
00:01:55,110 --> 00:01:57,150
and that's part
of the preventing

37
00:01:57,150 --> 00:02:01,200
the unwanted neighborships,
but this flood of traffic

38
00:02:01,200 --> 00:02:05,110
could very well overwhelm BGP.

39
00:02:05,110 --> 00:02:08,039
So it's best if BGP
can essentially throw

40
00:02:08,039 --> 00:02:10,840
the traffic away immediately.

41
00:02:10,840 --> 00:02:14,370
So the way this works
is, first, we're

42
00:02:14,370 --> 00:02:17,850
going to set the
TTL on all the BGP

43
00:02:17,850 --> 00:02:23,550
packets that were originating
to 255 rather than one.

44
00:02:23,550 --> 00:02:27,870
And then in conjunction with
that on the receiving side,

45
00:02:27,870 --> 00:02:30,480
we're only going
to allow packets

46
00:02:30,480 --> 00:02:34,470
that meet a minimum set TTL.

47
00:02:34,470 --> 00:02:38,610
Any packets that are
below that threshold

48
00:02:38,610 --> 00:02:40,860
are instantly discarded.

49
00:02:40,860 --> 00:02:45,930
That's how we're protecting
BGP because ultimately, that

50
00:02:45,930 --> 00:02:50,010
saves BGP from
processing those frames.

51
00:02:50,010 --> 00:02:52,500
Those frames aren't going
to be processed if we're

52
00:02:52,500 --> 00:02:54,490
discarding them right away.

53
00:02:54,490 --> 00:02:57,150
So let's take a
look at a chart here

54
00:02:57,150 --> 00:02:59,490
that's going to define
a little bit about how

55
00:02:59,490 --> 00:03:04,890
this works as far as options
go then with our eBGP peerings.

56
00:03:04,890 --> 00:03:09,030
So first and foremost, we
have what's our default.

57
00:03:09,030 --> 00:03:11,020
And of course, since
it's the default,

58
00:03:11,020 --> 00:03:13,710
it's not shown in
our configuration.

59
00:03:13,710 --> 00:03:18,570
But we default to ebgp-multihop
1, which, of course, means

60
00:03:18,570 --> 00:03:21,480
the TTL is 1, and
this is only going

61
00:03:21,480 --> 00:03:25,650
to accept connected routes
for reaching our neighborship.

62
00:03:25,650 --> 00:03:30,390
There's also no expected
TTL because, well, we're

63
00:03:30,390 --> 00:03:32,160
not doing TTL security.

64
00:03:32,160 --> 00:03:37,410
The expected TTL only applies
if we're doing TTL security.

65
00:03:37,410 --> 00:03:40,950
Next is the
disable-connected-check.

66
00:03:40,950 --> 00:03:45,660
If we enable this feature,
then the TTL is still 1.

67
00:03:45,660 --> 00:03:50,310
However, it will now
accept connected, dynamic,

68
00:03:50,310 --> 00:03:54,340
and static routes for
finding its neighbors.

69
00:03:54,340 --> 00:03:57,910
So it doesn't have to be
directly connected anymore.

70
00:03:57,910 --> 00:04:02,430
However, the TTL is still 1, and
there's still no expected TTL

71
00:04:02,430 --> 00:04:06,510
because, again, this
is not TTL security.

72
00:04:06,510 --> 00:04:11,160
Next is we have ebgp-multihop
X, which would be pretty

73
00:04:11,160 --> 00:04:13,530
much any number higher than 1.

74
00:04:13,530 --> 00:04:16,950
That means the TTL is going to
be whatever number you specify.

75
00:04:16,950 --> 00:04:20,160
And since it knows it's going
to be more than one hop away,

76
00:04:20,160 --> 00:04:23,340
once again, we can use
either connected, dynamic,

77
00:04:23,340 --> 00:04:25,200
or static routes.

78
00:04:25,200 --> 00:04:28,800
And again, we still don't
have any expected TTL.

79
00:04:28,800 --> 00:04:31,690
Again, still not TTL security.

80
00:04:31,690 --> 00:04:34,320
Now, for the options
that are actually

81
00:04:34,320 --> 00:04:39,750
related to our current topic,
ttl-security hops 1 means,

82
00:04:39,750 --> 00:04:42,630
we're going to set
the TTL to 255.

83
00:04:42,630 --> 00:04:46,540
We're, once again, only going
to accept connected routes,

84
00:04:46,540 --> 00:04:51,330
and we're going to
expect a TTL of 254.

85
00:04:51,330 --> 00:04:54,670
This means, of course, that a
neighbor can't be two or three

86
00:04:54,670 --> 00:04:57,450
or seven hops away
or 100 hops away

87
00:04:57,450 --> 00:05:02,520
because the TTL has to still
be 254 on the packet when

88
00:05:02,520 --> 00:05:03,870
it gets to me.

89
00:05:03,870 --> 00:05:06,580
Now, these options
can be combined.

90
00:05:06,580 --> 00:05:09,840
So we could do
ttl-security hops 1

91
00:05:09,840 --> 00:05:13,740
and turn on
disable-connected-check.

92
00:05:13,740 --> 00:05:18,480
What that does for us, it
still leaves the TTL at 255,

93
00:05:18,480 --> 00:05:21,930
and it still leaves
the expected at 254,

94
00:05:21,930 --> 00:05:25,260
but it allows us to
use connected, dynamic,

95
00:05:25,260 --> 00:05:27,870
and static routes.

96
00:05:27,870 --> 00:05:29,360
So in case you're
wondering why you

97
00:05:29,360 --> 00:05:31,580
would want that
option, that's going

98
00:05:31,580 --> 00:05:34,190
to be a really good
option if you are trying

99
00:05:34,190 --> 00:05:36,770
to peer with a directly
connected neighbor,

100
00:05:36,770 --> 00:05:40,760
but you're trying to
use loopback interfaces.

101
00:05:40,760 --> 00:05:43,970
Loopback interfaces are not
going to be connected routes.

102
00:05:43,970 --> 00:05:46,160
They're either going to
be statically configured

103
00:05:46,160 --> 00:05:49,280
or learned through a
dynamic routing protocol,

104
00:05:49,280 --> 00:05:51,110
some form of an IGP.

105
00:05:51,110 --> 00:05:54,020
But we can't use
that if we don't

106
00:05:54,020 --> 00:05:56,750
have disable-connected-check
because otherwise,

107
00:05:56,750 --> 00:06:00,490
it will only use
connected routes.

108
00:06:00,490 --> 00:06:05,680
Then, of course, we have the
option for ttl-security hops X,

109
00:06:05,680 --> 00:06:08,380
where we put in a
number higher than 1.

110
00:06:08,380 --> 00:06:10,120
Now, this, of
course, is not going

111
00:06:10,120 --> 00:06:14,170
to change the initial TTL
this time, unlike what

112
00:06:14,170 --> 00:06:16,570
it did with ebgp-multihop.

113
00:06:16,570 --> 00:06:22,150
The starting TTL with
ttl-security is always to 255.

114
00:06:22,150 --> 00:06:24,940
Now, what it does do
for us is bring along

115
00:06:24,940 --> 00:06:28,420
those connected, dynamic,
and static routes

116
00:06:28,420 --> 00:06:31,180
to use for our neighborship
because, again, we're

117
00:06:31,180 --> 00:06:34,700
telling the router essentially,
this is not connected.

118
00:06:34,700 --> 00:06:37,000
So it's going to use
those other routes.

119
00:06:37,000 --> 00:06:41,920
The way it's calculated is
the TTL when it arrives.

120
00:06:41,920 --> 00:06:46,060
So the expected TTL
is going to be greater

121
00:06:46,060 --> 00:06:50,890
than or equal to 255 minus x.

122
00:06:50,890 --> 00:06:56,860
So as an example, let's say
that we set our TTL hops to 5.

123
00:06:56,860 --> 00:07:00,520
This means that the answer
for the required TTL

124
00:07:00,520 --> 00:07:07,150
is going to be 255 minus 5,
which, of course, is 250.

125
00:07:07,150 --> 00:07:09,440
That means that when
a packet arrives,

126
00:07:09,440 --> 00:07:14,440
it's going to have to
have 250 or higher.

127
00:07:14,440 --> 00:07:18,740
Neighbors can be closer
but not further away.

128
00:07:18,740 --> 00:07:23,390
So if it arrives with a TTL
of 252, that's perfectly fine.

129
00:07:23,390 --> 00:07:24,445
It's closer.

130
00:07:24,445 --> 00:07:26,320
And that's what we said
down here in the note

131
00:07:26,320 --> 00:07:27,610
just to point it out.

132
00:07:27,610 --> 00:07:32,420
Again, neighbors can be
closer but not further away.

133
00:07:32,420 --> 00:07:34,300
So before we jump on
to the command-line

134
00:07:34,300 --> 00:07:37,300
and look at this, let's, of
course, look at our diagram

135
00:07:37,300 --> 00:07:39,470
and see what we're
going to be building.

136
00:07:39,470 --> 00:07:43,210
So very simply, we're
going to use TTL security

137
00:07:43,210 --> 00:07:46,300
on the link between R1 and R9.

138
00:07:46,300 --> 00:07:51,310
That way, we can see this
on IOS XE and IOS XR.

139
00:07:51,310 --> 00:07:54,460
However, we are going to do it
a little bit different than it

140
00:07:54,460 --> 00:07:55,360
is right now.

141
00:07:55,360 --> 00:07:58,270
Right now, they're peered
up on physical interfaces.

142
00:07:58,270 --> 00:08:02,600
We're going to actually peer
them up on loopback interfaces

143
00:08:02,600 --> 00:08:04,920
just to make it a little
bit more interesting.

144
00:08:04,920 --> 00:08:07,007
So let's jump on to
the command-line.

145
00:08:07,007 --> 00:08:08,840
The first thing, of
course, we'll have to do

146
00:08:08,840 --> 00:08:10,470
is some routing here.

147
00:08:10,470 --> 00:08:12,090
So we'll just do static routes.

148
00:08:12,090 --> 00:08:14,690
So the routers can get to
each other's loopbacks.

149
00:08:14,690 --> 00:08:16,820
Then we'll take out
the old neighborships,

150
00:08:16,820 --> 00:08:20,640
put in the new neighborships
with our TTL security.

151
00:08:20,640 --> 00:08:22,640
So let's go ahead and
jump into the command-line

152
00:08:22,640 --> 00:08:24,710
and get that done.

153
00:08:24,710 --> 00:08:27,190
So we'll start off
here on router 1.

154
00:08:27,190 --> 00:08:29,530
We're just going to paste
the configuration in,

155
00:08:29,530 --> 00:08:32,440
and all we're doing is
adding a static route

156
00:08:32,440 --> 00:08:34,659
to get to router 9's loopback.

157
00:08:34,659 --> 00:08:38,380
We'll do the same thing on
router 9 to get to router 1.

158
00:08:38,380 --> 00:08:40,630
And if that worked
correctly, we should

159
00:08:40,630 --> 00:08:44,410
be able to ping
10.1.1.1, sourcing it

160
00:08:44,410 --> 00:08:46,900
from our loopback0 interface.

161
00:08:46,900 --> 00:08:48,860
We see this as successful.

162
00:08:48,860 --> 00:08:51,910
So now, we can change
our BGP neighborships.

163
00:08:51,910 --> 00:08:54,250
Let's go back over to router 1.

164
00:08:54,250 --> 00:08:56,870
This is a fairly
standard configuration.

165
00:08:56,870 --> 00:08:58,810
So once again, we'll
just paste it in,

166
00:08:58,810 --> 00:09:00,700
and I'll just
highlight the commands

167
00:09:00,700 --> 00:09:03,850
that are a little bit different
from what we've been doing.

168
00:09:03,850 --> 00:09:06,950
So two things that are
going to make this work.

169
00:09:06,950 --> 00:09:09,760
First, we have the command
here under the neighborship

170
00:09:09,760 --> 00:09:12,070
to ignore the connected check.

171
00:09:12,070 --> 00:09:13,600
That's what's
going to allow this

172
00:09:13,600 --> 00:09:17,020
to come up between our
loopback interfaces.

173
00:09:17,020 --> 00:09:19,360
And then we have
our TTL security,

174
00:09:19,360 --> 00:09:20,980
which is going to
have and initiate

175
00:09:20,980 --> 00:09:25,050
our packets with a TTL of 255.

176
00:09:25,050 --> 00:09:28,820
Now, let's go make the similar
configuration on router 9.

177
00:09:28,820 --> 00:09:31,520
So once again, we'll take
out the old neighborship.

178
00:09:31,520 --> 00:09:33,830
We'll put in the
new neighborship,

179
00:09:33,830 --> 00:09:35,930
again, sourcing it
from our loopbacks

180
00:09:35,930 --> 00:09:40,640
with our ttl-security hops 1
and our disable-connected-check,

181
00:09:40,640 --> 00:09:44,330
and we see here that our
neighborship with router 1

182
00:09:44,330 --> 00:09:46,700
has, in fact, come up.

183
00:09:46,700 --> 00:09:48,410
Now, something
else we can do here

184
00:09:48,410 --> 00:09:53,330
is do a show ip bgp for
the neighbor 10.1.1.1,

185
00:09:53,330 --> 00:09:56,960
and we'll ask to
include the TTL.

186
00:09:56,960 --> 00:09:58,790
What we're looking
for specifically

187
00:09:58,790 --> 00:10:05,000
here is that the minimum
incoming TTL is 254.

188
00:10:05,000 --> 00:10:09,440
That's, of course, the
255 minus the one hop

189
00:10:09,440 --> 00:10:12,710
that we said this neighbor
was allowed to be away.

190
00:10:12,710 --> 00:10:17,730
Also note that the
outgoing TTL is now 255.

191
00:10:17,730 --> 00:10:22,400
So we can see that this is up
and working with TTL security.

192
00:10:22,400 --> 00:10:25,890
Let's verify this, of
course, on router 1 as well.

193
00:10:25,890 --> 00:10:29,480
We'll do a show bgp
neighbor for 10.9.9.9.

194
00:10:29,480 --> 00:10:32,120
And if we look at our
last three lines here,

195
00:10:32,120 --> 00:10:35,060
these are the lines related
to what we just configured.

196
00:10:35,060 --> 00:10:37,910
The TTL security is configured.

197
00:10:37,910 --> 00:10:41,840
The external BGP neighbor
is not directly connected,

198
00:10:41,840 --> 00:10:46,670
and the next hop check is
bypassed for this external BGP

199
00:10:46,670 --> 00:10:47,750
neighbor.

200
00:10:47,750 --> 00:10:50,090
And just as a final
verification so

201
00:10:50,090 --> 00:10:52,850
we can see how the
TTL is calculated,

202
00:10:52,850 --> 00:10:55,880
let's go back to
router 9, and let's

203
00:10:55,880 --> 00:11:01,460
reconfigure this, this
time with a hop count of 3

204
00:11:01,460 --> 00:11:03,110
for the neighborship.

205
00:11:03,110 --> 00:11:06,230
If we look at this
again now, we see

206
00:11:06,230 --> 00:11:10,400
that the minimum
incoming TTL is now 252.

207
00:11:10,400 --> 00:11:14,870
So that's our 255 minus
the three hops that we

208
00:11:14,870 --> 00:11:16,610
said it's allowed to be away.

209
00:11:16,610 --> 00:11:20,540
So we can see here how
that minimum incoming TTL

210
00:11:20,540 --> 00:11:23,200
is calculated.

211
00:11:23,200 --> 00:11:27,760
In this video, we looked
at how TTL security can

212
00:11:27,760 --> 00:11:31,420
be used to prevent neighbors
from coming up that are further

213
00:11:31,420 --> 00:11:33,610
away than we want them to be.

214
00:11:33,610 --> 00:11:35,570
The advantage to
this, of course,

215
00:11:35,570 --> 00:11:39,460
is that it allows BGP
itself to quickly throw away

216
00:11:39,460 --> 00:11:44,420
those packets if the TTL is
below the minimum threshold,

217
00:11:44,420 --> 00:11:48,290
therefore, preventing BGP
from getting overwhelmed.

218
00:11:48,290 --> 00:11:50,470
I hope this has been
informative for you,

219
00:11:50,470 --> 00:11:53,640
and I'd like to thank
you for viewing.

220
00:11:53,640 --> 00:11:57,000