WEBVTT

1
00:00.000 --> 00:08.940
Next up, let's take a look at the BGP path selection process and how BGP

2
00:08.940 --> 00:09.440
chooses the

3
00:09.440 --> 00:12.240
best path that it's going to use.

4
00:12.240 --> 00:16.480
Now, this is pretty far from a simple process.

5
00:16.480 --> 00:22.490
In fact, it's rather complex with a lot of little caveats and gotchas along the

6
00:22.490 --> 00:23.080
way.

7
00:23.080 --> 00:28.520
Also be aware that different vendors may implement different details a little

8
00:28.520 --> 00:29.880
bit differently.

9
00:29.880 --> 00:34.720
There are, of course, standards in the RFCs for BGP, but that doesn't mean that
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

9
00:29.880 --> 00:34.720
There are, of course, standards in the RFCs for BGP, but that doesn't mean that

10
00:34.720 --> 00:35.200
there

11
00:35.200 --> 00:40.400
can't be modifications or interpretations of how to implement it.

12
00:40.400 --> 00:46.350
So I always find the best way to research or learn the BGP best path selection

13
00:46.350 --> 00:47.080
process

14
00:47.080 --> 00:52.760
for a particular vendor is to go look at that vendor's documented process.

15
00:52.760 --> 00:58.940
So because of that, let's jump into Cisco's webpage and take a look at the BGP

16
00:58.940 --> 00:59.840
path selection

17
00:59.840 --> 01:00.840
process.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

17
00:59.840 --> 01:00.840
process.

18
01:00.840 --> 01:06.060
We'll also wrap this video up with taking a look at some of our methods of

19
01:06.060 --> 01:06.680
injecting

20
01:06.680 --> 01:09.320
routes into BGP as well.

21
01:09.320 --> 01:14.400
But for right now, let's jump over to Cisco's website for the BGP path

22
01:14.400 --> 01:16.160
selection process.

23
01:16.160 --> 01:23.140
So here we're on Cisco's website looking at the select BGP best path algorithm

24
01:23.140 --> 01:24.280
document.

25
01:24.280 --> 01:29.420
And there's really sort of two major sections of this document that we want to

26
01:29.420 --> 01:30.240
look at.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

26
01:29.420 --> 01:30.240
look at.

27
01:30.240 --> 01:31.320
So let's scroll down here.

28
01:31.320 --> 01:35.410
We can see it sort of at the bottom of the page right now to the wide routers

29
01:35.410 --> 01:36.360
ignore paths

30
01:36.360 --> 01:37.720
section.

31
01:37.720 --> 01:42.430
So let's take a look at some of these reasons because, of course, routers

32
01:42.430 --> 01:43.520
ignoring paths

33
01:43.520 --> 01:47.080
would sort of be a major part of our troubleshooting.

34
01:47.080 --> 01:53.000
Now the first one here paths that are not marked as synchronized.

35
01:53.000 --> 01:55.480
This is sort of an older technology.

36
01:55.480 --> 02:01.390
It had to do with IBGP learned routes also had to be learned by the underlying
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

36
01:55.480 --> 02:01.390
It had to do with IBGP learned routes also had to be learned by the underlying

37
02:01.390 --> 02:02.120
IGP such

38
02:02.120 --> 02:04.720
as OSPF.

39
02:04.720 --> 02:08.980
And there was another rule that they reference over here where the OSPF router

40
02:08.980 --> 02:09.600
ID and the

41
02:09.600 --> 02:12.560
BGP router ID had to match.

42
02:12.560 --> 02:16.480
So there's some little caveats to this rule as well.

43
02:16.480 --> 02:19.160
But take a look at their note.

44
02:19.160 --> 02:28.000
The realization is actually disabled by default starting with iOS 12 to 8 T.

45
02:28.000 --> 02:32.240
That's actually fairly old code at this point.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

45
02:28.000 --> 02:32.240
That's actually fairly old code at this point.

46
02:32.240 --> 02:38.050
So what I'm really trying to say is this first one probably will not apply in

47
02:38.050 --> 02:39.800
most cases.

48
02:39.800 --> 02:46.880
Now the next rule paths for which the next hop is inaccessible.

49
02:46.880 --> 02:48.320
That's a big one.

50
02:48.320 --> 02:50.240
People star this one.

51
02:50.240 --> 02:55.490
This is probably the number one reason that you're going to run into that paths

52
02:55.490 --> 02:56.080
are not

53
02:56.080 --> 02:58.480
being used by BGP.

54
02:58.480 --> 03:01.280
They don't know how to get to the next hop.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

54
02:58.480 --> 03:01.280
They don't know how to get to the next hop.

55
03:01.280 --> 03:06.850
What good is a path to a network if I don't know how to get to the next hop to

56
03:06.850 --> 03:08.120
that network?

57
03:08.120 --> 03:10.440
So it makes sense that we would ignore it.

58
03:10.440 --> 03:14.160
But it's also one of the most common problems.

59
03:14.160 --> 03:20.790
Now the next rule here paths from an E BGP neighbor if the local AS number

60
03:20.790 --> 03:22.200
appears in

61
03:22.200 --> 03:24.280
the AS path.

62
03:24.280 --> 03:29.150
Now while you were reading or studying BGP originally, you probably just heard

63
03:29.150 --> 03:29.720
this one

64
03:29.720 --> 03:33.660
referred to as BGP loop prevention.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

64
03:29.720 --> 03:33.660
referred to as BGP loop prevention.

65
03:33.660 --> 03:38.800
We discard updates that have our own AS in the AS path.

66
03:38.800 --> 03:41.200
Now there are some ways to get around that.

67
03:41.200 --> 03:44.080
You can say things like allow AS in.

68
03:44.080 --> 03:45.600
There's ways to get around this.

69
03:45.600 --> 03:50.760
But the basic loop prevention mechanism is to not accept the path that has our

70
03:50.760 --> 03:51.520
own AS

71
03:51.520 --> 03:53.560
in the AS path.

72
03:53.560 --> 03:58.050
Now the last two here, honestly, are going to be fairly unusual where we

73
03:58.050 --> 03:59.600
receive an update

74
03:59.600 --> 04:05.470
where we have enabled BGP in force first AS and the update does not contain the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

74
03:59.600 --> 04:05.470
where we have enabled BGP in force first AS and the update does not contain the

75
04:05.470 --> 04:06.480
neighboring

76
04:06.480 --> 04:09.320
AS as the first AS in the sequence.

77
04:09.320 --> 04:14.480
Again, that one's sort of a sanity check, but it's not generally enabled.

78
04:14.480 --> 04:17.680
But we would discard the update if that was the case.

79
04:17.680 --> 04:23.400
And this last one is simply talking about paths that are marked as received

80
04:23.400 --> 04:23.720
only and

81
04:23.720 --> 04:26.800
they're not actually being used.

82
04:26.800 --> 04:30.280
This is often going to be because one of the reasons above.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

82
04:26.800 --> 04:30.280
This is often going to be because one of the reasons above.

83
04:30.280 --> 04:35.250
However, it's simply telling you here that you can see these rejected paths if

84
04:35.250 --> 04:35.600
you've

85
04:35.600 --> 04:40.680
configured soft reconfiguration inbound for that neighbor.

86
04:40.680 --> 04:44.840
So these are all the reasons why we might ignore the paths.

87
04:44.840 --> 04:45.840
Let's scroll down here.

88
04:45.840 --> 04:49.920
We can see it's the next section, but let's bring more of it up onto the screen

89
04:49.920 --> 04:49.920
about

90
04:49.920 --> 04:53.640
how the best path algorithm actually works.

91
04:53.640 --> 04:55.240
So this is a fairly long list.

92
04:55.240 --> 04:59.560
We're going to go through it relatively quickly, just hitting some of the major

93
04:59.560 --> 05:00.480
highlights.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

93
04:59.560 --> 05:00.480
highlights.

94
05:00.480 --> 05:07.080
So rule number one is we're going to prefer the path with the highest weight.

95
05:07.080 --> 05:13.080
Now be aware that weight is Cisco specific or you could say Cisco proprietary.

96
05:13.080 --> 05:17.700
That means that this is only local to the router and it's never going to be

97
05:17.700 --> 05:18.240
sent to

98
05:18.240 --> 05:19.880
neighbors.

99
05:19.880 --> 05:22.280
Cisco put this in there for a few different reasons.

100
05:22.280 --> 05:26.800
One of the primary reasons is to aid with loop prevention.

101
05:26.800 --> 05:30.360
Just a little bit of a complex discussion we don't really need to have here.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

101
05:26.800 --> 05:30.360
Just a little bit of a complex discussion we don't really need to have here.

102
05:30.360 --> 05:34.680
I'm just bringing it up because a lot of people look at this and say, why did

103
05:34.680 --> 05:35.440
Cisco even

104
05:35.440 --> 05:37.800
create weight?

105
05:37.800 --> 05:43.680
Trust me, there's some good reasons for it, but it is Cisco proprietary.

106
05:43.680 --> 05:47.680
Now other vendors may have implemented something very similar, but we're having

107
05:47.680 --> 05:48.680
a Cisco discussion

108
05:48.680 --> 05:50.320
right now.

109
05:50.320 --> 05:56.680
Number two, once again, we're highest, but this time it's local prep.

110
05:56.680 --> 06:02.810
Now local preference is a global parameter, meaning everybody understands local
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

110
05:56.680 --> 06:02.810
Now local preference is a global parameter, meaning everybody understands local

111
06:02.810 --> 06:03.760
preference

112
06:03.760 --> 06:06.400
and the highest wins.

113
06:06.400 --> 06:11.160
It does have a value of 100 by default.

114
06:11.160 --> 06:16.600
Number three, you can see actually has some caveats here, which we probably don

115
06:16.600 --> 06:17.320
't really

116
06:17.320 --> 06:23.220
have to get into the detail on, but basically we're going to prefer locally

117
06:23.220 --> 06:24.520
originated.

118
06:24.520 --> 06:29.040
Now it's going to be a little more specific down here where it's saying that if

119
06:29.040 --> 06:29.560
they were

120
06:29.560 --> 06:34.310
sourced by the network or redistribution command, they're going to be preferred
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

120
06:29.560 --> 06:34.310
sourced by the network or redistribution command, they're going to be preferred

121
06:34.310 --> 06:34.520
over

122
06:34.520 --> 06:35.520
local aggregates.

123
06:35.520 --> 06:40.460
And again, we're starting to get into some real detail there on how this works,

124
06:40.460 --> 06:40.640
but I

125
06:40.640 --> 06:46.920
would just summarize rule three to be preferred locally originated over learned

126
06:46.920 --> 06:47.880
routes.

127
06:47.880 --> 06:53.000
Number four, we finally get to the shortest AS path.

128
06:53.000 --> 06:55.600
So this is fairly straightforward.

129
06:55.600 --> 07:00.190
If one path has three as is in the as path and the other one has to, then we're
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

129
06:55.600 --> 07:00.190
If one path has three as is in the as path and the other one has to, then we're

130
07:00.190 --> 07:00.560
going

131
07:00.560 --> 07:04.400
to go with the one that has to in the as path.

132
07:04.400 --> 07:09.450
Now once again, there are a few little caveats here about how this can be

133
07:09.450 --> 07:10.400
ignored.

134
07:10.400 --> 07:15.030
If we have the BGP best path as path ignore command configured, which you

135
07:15.030 --> 07:16.200
generally don't

136
07:16.200 --> 07:22.260
want to do number four is a fairly common rule here where BGP decisions happen,

137
07:22.260 --> 07:22.480
but you

138
07:22.480 --> 07:25.120
can disable this if you want.

139
07:25.120 --> 07:29.960
So that command basically disables the shortest path rule.

140
07:29.960 --> 07:35.050
If you're using an AS set, which again is sort of an advanced BGP feature, that
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

140
07:29.960 --> 07:35.050
If you're using an AS set, which again is sort of an advanced BGP feature, that

141
07:35.050 --> 07:35.440
set

142
07:35.440 --> 07:41.490
is going to count as one and sort of along the same vein of complicated topics,

143
07:41.490 --> 07:42.240
the as

144
07:42.240 --> 07:47.820
confed sequence and as confed set, go along with this if you're using confeder

145
07:47.820 --> 07:48.400
ations.

146
07:48.400 --> 07:53.380
Again, little beyond the scope of what we're talking about, just think about

147
07:53.380 --> 07:53.960
four as the

148
07:53.960 --> 07:58.360
shortest as path with a few minor caveats.

149
07:58.360 --> 08:02.900
One other thing I'll mention about rule number four here is simply a memory
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

149
07:58.360 --> 08:02.900
One other thing I'll mention about rule number four here is simply a memory

150
08:02.900 --> 08:04.040
trick that might

151
08:04.040 --> 08:10.280
help you remember some of these things because notice that so far everything

152
08:10.280 --> 08:11.800
has been highest,

153
08:11.800 --> 08:16.640
highest weight, highest local preference doesn't really apply to rule number

154
08:16.640 --> 08:16.920
three.

155
08:16.920 --> 08:22.490
But now as we move on to rule number five and below, everything down here is

156
08:22.490 --> 08:23.000
going to

157
08:23.000 --> 08:24.560
be lowest.

158
08:24.560 --> 08:29.420
So one trick I've always sort of used to remember which values higher wins and

159
08:29.420 --> 08:31.160
which value lower
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

159
08:29.420 --> 08:31.160
which value lower

160
08:31.160 --> 08:32.600
wins.

161
08:32.600 --> 08:38.430
Think about the rule that is shortest, draw a line there and everything higher

162
08:38.430 --> 08:39.160
than this

163
08:39.160 --> 08:46.440
rule, higher value wins and everything lower than this rule, lower value wins.

164
08:46.440 --> 08:51.000
So for me, I sort of refer to this as the turning point rule.

165
08:51.000 --> 08:56.240
But nonetheless, you can use it to sort of remember which values higher or

166
08:56.240 --> 08:57.320
lower wins.

167
08:57.320 --> 09:03.240
So next we have rule number five, which is simply the lowest origin type.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

167
08:57.320 --> 09:03.240
So next we have rule number five, which is simply the lowest origin type.

168
09:03.240 --> 09:07.360
Origin is simply going to be IE or question mark.

169
09:07.360 --> 09:09.320
And we prefer them in that order.

170
09:09.320 --> 09:13.880
An I beats out an E and an E beats out a question mark.

171
09:13.880 --> 09:18.800
In most environments, you're only going to see an I or a question mark.

172
09:18.800 --> 09:23.560
E is from EGP, which is sort of a dead protocol.

173
09:23.560 --> 09:29.040
But some people manually set that origin type in order to use rule five as part

174
09:29.040 --> 09:29.680
of the past

175
09:29.680 --> 09:31.920
selection criteria.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

175
09:29.680 --> 09:31.920
selection criteria.

176
09:31.920 --> 09:35.880
Next we get to rule number six and all the way down here, we're looking again

177
09:35.880 --> 09:36.320
at the

178
09:36.320 --> 09:42.280
lowest and now we're finally looking at the multi exit discriminator or the med

179
09:42.280 --> 09:42.920
or as Cisco

180
09:42.920 --> 09:45.520
calls it the metric.

181
09:45.520 --> 09:48.080
And we are not going to get into this.

182
09:48.080 --> 09:52.160
This is getting way too deep into the past selection process.

183
09:52.160 --> 09:54.880
But let's clean up our markings and scroll down here a little bit.

184
09:54.880 --> 09:57.240
I just want you to see something.

185
09:57.240 --> 09:59.960
So now moving six up to the top of the screen.

186
09:59.960 --> 10:03.680
Again, we're talking about the lowest med here.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

186
09:59.960 --> 10:03.680
Again, we're talking about the lowest med here.

187
10:03.680 --> 10:08.000
Look at all of the caveats on med.

188
10:08.000 --> 10:10.160
And again, we're not going to go over all of this.

189
10:10.160 --> 10:15.210
You can see that this gets very complicated, but there are a lot of rules and

190
10:15.210 --> 10:16.080
caveats for

191
10:16.080 --> 10:18.520
how med actually works.

192
10:18.520 --> 10:23.570
This by the way is one of those areas where different vendors may vary just a

193
10:23.570 --> 10:24.480
little bit

194
10:24.480 --> 10:25.480
here.

195
10:25.480 --> 10:31.320
They sort of address that in this section right here about what happens if we
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

195
10:25.480 --> 10:31.320
They sort of address that in this section right here about what happens if we

196
10:31.320 --> 10:31.960
receive

197
10:31.960 --> 10:36.920
meds with missing values or meds with zeros versus nothing.

198
10:36.920 --> 10:41.250
It gets a little complicated because the standard never really says what should

199
10:41.250 --> 10:42.080
happen if there's

200
10:42.080 --> 10:44.200
an empty med field.

201
10:44.200 --> 10:48.760
So it's sort of been open to interpretation from the different vendors.

202
10:48.760 --> 10:50.680
So moving on to rule seven.

203
10:50.680 --> 10:52.600
This one's fairly simple.

204
10:52.600 --> 10:58.480
Prefer a route learned by eBGP over a route learned from IBGP.

205
10:58.480 --> 11:04.400
This is basically just saying prefer external routes over internal routes.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

205
10:58.480 --> 11:04.400
This is basically just saying prefer external routes over internal routes.

206
11:04.400 --> 11:09.020
Again, there's a little bit of a caveat here if you're using confederations,

207
11:09.020 --> 11:09.600
but we're

208
11:09.600 --> 11:12.800
not getting into all of that right now.

209
11:12.800 --> 11:16.520
Rule number eight is actually sort of an interesting rule.

210
11:16.520 --> 11:20.880
It's going to go back and look at the lowest IGP metric.

211
11:20.880 --> 11:27.730
So it's actually going to look to the underlay protocol such as OSPF or EIGRP

212
11:27.730 --> 11:28.720
and choose

213
11:28.720 --> 11:32.600
the lowest metric to that next hop address.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

213
11:28.720 --> 11:32.600
the lowest metric to that next hop address.

214
11:32.600 --> 11:37.870
In other words, it's basically trying to choose its closest exit point from

215
11:37.870 --> 11:39.520
your environment.

216
11:39.520 --> 11:42.240
Number nine is just sort of straightforward.

217
11:42.240 --> 11:47.280
It's making a decision of whether to install multiple routes into the routing

218
11:47.280 --> 11:47.720
table.

219
11:47.720 --> 11:53.010
If you have enabled multi-path and you get all the way down to rule nine as a

220
11:53.010 --> 11:53.640
tie, you

221
11:53.640 --> 11:58.640
will then install both or all of the routes into the routing table.

222
11:58.640 --> 12:04.280
Once we get down to 10, we're honestly just down to tie breakers here.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

222
11:58.640 --> 12:04.280
Once we get down to 10, we're honestly just down to tie breakers here.

223
12:04.280 --> 12:09.050
If both of the paths are external, this is only going to kick in if we made it

224
12:09.050 --> 12:09.760
through

225
12:09.760 --> 12:15.440
rule seven with both of the paths being external, it's going to prefer the one

226
12:15.440 --> 12:17.080
it received first

227
12:17.080 --> 12:19.800
or the oldest update.

228
12:19.800 --> 12:24.000
The logic behind this is simply if one route is flapping, we really don't want

229
12:24.000 --> 12:24.600
to prefer

230
12:24.600 --> 12:28.760
that when we want to prefer the one that has been the most stable.

231
12:28.760 --> 12:33.690
So let's clear this off, scroll down a little more, and now we're really down
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

231
12:28.760 --> 12:33.690
So let's clear this off, scroll down a little more, and now we're really down

232
12:33.690 --> 12:34.960
to tie breakers.

233
12:34.960 --> 12:39.880
Rule number 11 here says to prefer the route that comes from the BGP router

234
12:39.880 --> 12:40.880
with the lowest

235
12:40.880 --> 12:45.680
router ID, which of course really has nothing to do with the best path.

236
12:45.680 --> 12:48.880
This is literally just flipping a coin.

237
12:48.880 --> 12:52.480
Just pick the one with the lowest router ID.

238
12:52.480 --> 12:58.780
Number 12 comes into play because if we have clusters involved, we're going to

239
12:58.780 --> 12:59.400
go with

240
12:59.400 --> 13:02.400
the minimum cluster list length.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

240
12:59.400 --> 13:02.400
the minimum cluster list length.

241
13:02.400 --> 13:06.680
Again, we're not going to get into talking about clusters and BGP route reflect

242
13:06.680 --> 13:07.280
ors right

243
13:07.280 --> 13:10.760
now, but that's what this has to do with.

244
13:10.760 --> 13:15.860
And finally, at the end of the day, rule number 13 here, if all else fails, if

245
13:15.860 --> 13:16.560
you make it

246
13:16.560 --> 13:20.920
all the way down to here and somehow still have a tie, then you're literally

247
13:20.920 --> 13:21.600
just going

248
13:21.600 --> 13:26.720
to flip a coin here and pick the lowest neighbor address.

249
13:26.720 --> 13:27.960
That's it.

250
13:27.960 --> 13:32.440
And of course, because of rule 13, we can clearly see there's no way to come
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

250
13:27.960 --> 13:32.440
And of course, because of rule 13, we can clearly see there's no way to come

251
13:32.440 --> 13:32.960
out the

252
13:32.960 --> 13:35.880
bottom of this list with a tie.

253
13:35.880 --> 13:39.760
Therefore, BGP will always choose a best path.

254
13:39.760 --> 13:43.940
Now, we're not going to do it here, but if you like, you can see that starting

255
13:43.940 --> 13:44.360
right

256
13:44.360 --> 13:49.070
here on this page and going to the bottom of the page are a bunch of examples

257
13:49.070 --> 13:49.760
and such

258
13:49.760 --> 13:55.240
of how BGP is going to go through this best path selection process.

259
13:55.240 --> 14:02.240
But for now, let's switch over and talk about how we inject paths into BGP.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

259
13:55.240 --> 14:02.240
But for now, let's switch over and talk about how we inject paths into BGP.

260
14:02.240 --> 14:04.800
So again, let's talk about route injection.

261
14:04.800 --> 14:09.320
So how do we actually put prefixes into BGP?

262
14:09.320 --> 14:14.920
Well, there's sort of three primary methods to do this, although honestly, only

263
14:14.920 --> 14:15.400
two of

264
14:15.400 --> 14:18.520
them are really done very frequently.

265
14:18.520 --> 14:21.160
The first is to do redistribution.

266
14:21.160 --> 14:25.480
We simply redistribute another protocol into BGP.

267
14:25.480 --> 14:31.720
Now, depending why we're using BGP, this may or may not be a common method.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

267
14:25.480 --> 14:31.720
Now, depending why we're using BGP, this may or may not be a common method.

268
14:31.720 --> 14:37.390
If we're using this for something like MPLS, then this is going to be a fairly

269
14:37.390 --> 14:38.080
common way

270
14:38.080 --> 14:43.750
to get our prefixes into BGP because it's going to be very closely working with

271
14:43.750 --> 14:44.120
our

272
14:44.120 --> 14:46.120
IGP.

273
14:46.120 --> 14:51.390
On the other hand, if this is for internet access, it's really sort of frowned

274
14:51.390 --> 14:51.840
upon to

275
14:51.840 --> 14:57.600
redistribute your IGP into BGP at your internet edge.

276
14:57.600 --> 15:00.520
Instead what you would want to do is use a network statement.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

276
14:57.600 --> 15:00.520
Instead what you would want to do is use a network statement.

277
15:00.520 --> 15:06.050
Again, this is going to be mostly for internet where we directly inject a

278
15:06.050 --> 15:07.840
network into BGP.

279
15:07.840 --> 15:15.070
Now one caveat of the network statement, this absolutely positively must be an

280
15:15.070 --> 15:15.720
exact

281
15:15.720 --> 15:16.720
match.

282
15:16.720 --> 15:19.040
Let me say that again.

283
15:19.040 --> 15:24.840
An exact match to a route that's already in your routing table.

284
15:24.840 --> 15:27.680
So maybe you have a static route.

285
15:27.680 --> 15:30.560
Maybe you've learned a route through a SPF.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

285
15:27.680 --> 15:30.560
Maybe you've learned a route through a SPF.

286
15:30.560 --> 15:33.920
Maybe it's just an address on a local interface.

287
15:33.920 --> 15:40.600
However that network that you want to put into BGP is in your routing table has

288
15:40.600 --> 15:41.240
to be

289
15:41.240 --> 15:44.680
exactly what you put in the network statement.

290
15:44.680 --> 15:51.460
In other words, if it's a slash 24, if it's a slash 16, if it's a slash 28, the

291
15:51.460 --> 15:52.240
address

292
15:52.240 --> 15:58.560
and the mask must be an exact match or the network statement will ignore it.

293
15:58.560 --> 16:03.080
Clearly, this is a very common thing to make a mistake on.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

293
15:58.560 --> 16:03.080
Clearly, this is a very common thing to make a mistake on.

294
16:03.080 --> 16:07.200
So be very, very careful with your network statements and always compare them

295
16:07.200 --> 16:07.640
to your

296
16:07.640 --> 16:08.960
routing table.

297
16:08.960 --> 16:11.880
They have to match the final method.

298
16:11.880 --> 16:13.840
And I'm not going to get into it here.

299
16:13.840 --> 16:17.040
I just wanted to put it on the list for completeness.

300
16:17.040 --> 16:19.960
This is a rather advanced BGP topic.

301
16:19.960 --> 16:23.800
However, you can also do a conditional route injection.

302
16:23.800 --> 16:28.820
Essentially what you're saying is, if I have this route in my routing table,

303
16:28.820 --> 16:29.720
then inject

304
16:29.720 --> 16:31.440
this other route.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

304
16:29.720 --> 16:31.440
this other route.

305
16:31.440 --> 16:35.160
Edit involves a bunch of route maps and configuration and it's a rather

306
16:35.160 --> 16:36.400
complicated thing to set

307
16:36.400 --> 16:37.400
up.

308
16:37.400 --> 16:41.720
However, it is another choice to get routes into BGP.

309
16:41.720 --> 16:46.580
And of course, once we have routes in BGP, something else that you may want to

310
16:46.580 --> 16:47.960
do is aggregate

311
16:47.960 --> 16:51.600
or summarize those addresses.

312
16:51.600 --> 16:55.920
In BGP, we do this with the aggregate address command.

313
16:55.920 --> 17:00.130
You simply say aggregate address and then after it, you put in what you want
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

313
16:55.920 --> 17:00.130
You simply say aggregate address and then after it, you put in what you want

314
17:00.130 --> 17:00.960
the aggregate

315
17:00.960 --> 17:02.920
address to be.

316
17:02.920 --> 17:08.400
Once again, like most things in BGP, this can get complicated.

317
17:08.400 --> 17:14.880
Because if I had to estimate 8 to 10 options on the aggregate address command,

318
17:14.880 --> 17:15.120
that do

319
17:15.120 --> 17:17.640
a whole bunch of different things.

320
17:17.640 --> 17:22.720
But overall, the way we do route summarization or aggregation is with the

321
17:22.720 --> 17:24.080
aggregate address

322
17:24.080 --> 17:25.840
command.

323
17:25.840 --> 17:30.640
So in this video, we took a look at sort of three major parts of BGP when it
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

323
17:25.840 --> 17:30.640
So in this video, we took a look at sort of three major parts of BGP when it

324
17:30.640 --> 17:31.320
comes to

325
17:31.320 --> 17:32.880
network paths.

326
17:32.880 --> 17:37.470
First, we took a look at why the router would ignore certain paths that it's

327
17:37.470 --> 17:38.160
learning from

328
17:38.160 --> 17:39.640
its neighbors.

329
17:39.640 --> 17:44.050
Always important things to keep an eye on when we're talking about troubles

330
17:44.050 --> 17:44.520
hooting.

331
17:44.520 --> 17:49.870
Then we talked about the BGP path selection process, all the rules, 13

332
17:49.870 --> 17:51.720
according to Cisco,

333
17:51.720 --> 17:55.200
all the rules that we go through when choosing the best path.

334
17:55.200 --> 17:58.010
And of course, that's important to note, because if you're trying to troublesh

335
17:58.010 --> 17:58.320
oot the

336
17:58.320 --> 18:02.870
router, sending traffic the wrong way, you have to understand why it's choosing
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

336
17:58.320 --> 18:02.870
router, sending traffic the wrong way, you have to understand why it's choosing

337
18:02.870 --> 18:03.440
to do

338
18:03.440 --> 18:04.440
that.

339
18:04.440 --> 18:08.780
And then I would probably keep that link handy when you're troubleshooting BGP

340
18:08.780 --> 18:09.600
and reference

341
18:09.600 --> 18:11.360
the best path algorithm.

342
18:11.360 --> 18:16.280
Finally, of course, we took a look at here how to inject routes into BGP.

343
18:16.280 --> 18:20.480
And remember, the most important thing here is when we use the incredibly

344
18:20.480 --> 18:21.320
common way of

345
18:21.320 --> 18:26.480
doing this of the network statement, that the network statement has to be an

346
18:26.480 --> 18:28.000
exact match

347
18:28.000 --> 18:34.120
for the prefix and the subnet mask length that we have already in our routing
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

347
18:28.000 --> 18:34.120
for the prefix and the subnet mask length that we have already in our routing

348
18:34.120 --> 18:35.000
table.

349
18:35.000 --> 18:40.440
You can't inject a route using the network statement unless you already have it

350
18:40.440 --> 18:40.840
in your

351
18:40.840 --> 18:42.240
regular routing table.

352
18:42.240 --> 18:47.200
The way to look at that is you have to be the owner of it, it being in your

353
18:47.200 --> 18:48.920
routing table

354
18:48.920 --> 18:52.640
before BGP will let you tell it to others.

355
18:52.640 --> 18:54.960
That's the idea behind that rule.

356
18:54.960 --> 18:59.600
So now that we have this all down, the next thing we want to do is jump in and

357
18:59.600 --> 19:00.080
do some
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

357
18:59.600 --> 19:00.080
do some

358
19:00.080 --> 19:03.200
actual troubleshooting with BGP.

359
19:03.200 --> 19:05.760
That's exactly what we're going to do in the next video.

360
19:05.760 --> 19:14.840
[BLANK_AUDIO]