WEBVTT

1
00:00.000 --> 00:04.400
For our discussion regarding border gateway protocol, let's use this topology.

2
00:04.400 --> 00:07.120
So I have, I believe there's 10 routers here.

3
00:07.120 --> 00:13.930
I've got R11, R12, R13, and over here I've got R21 and 22, and so forth and so

4
00:13.930 --> 00:14.240
on.

5
00:14.240 --> 00:17.680
I've also positioned these routers within these clouds, and these clouds

6
00:17.680 --> 00:19.200
represent autonomous system.

7
00:19.200 --> 00:23.760
So when we see the acronym AS, that stands for autonomous system.

8
00:23.760 --> 00:26.800
So one service provider may be in charge of this autonomous system.

9
00:26.800 --> 00:30.480
Let's say it's a autonomous system 10 and a different service provider is
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

9
00:26.800 --> 00:30.480
Let's say it's a autonomous system 10 and a different service provider is

10
00:30.480 --> 00:32.320
responsible for autonomous system 20,

11
00:32.320 --> 00:35.710
and another one for autonomous system 30, and another one for autonomous system

12
00:35.710 --> 00:36.000
40.

13
00:36.000 --> 00:39.520
AS for short, and the autonomous systems have a number assigned to them.

14
00:39.520 --> 00:43.760
And as part of that autonomous system, a service provider is very likely also

15
00:43.760 --> 00:45.360
to have blocks of

16
00:45.360 --> 00:49.360
internet reachable addresses associated or assigned to those service providers.

17
00:49.360 --> 00:52.720
And then to share routing information using border gateway protocol,

18
00:52.720 --> 00:56.320
the routers are going to be set up as BGP peers.

19
00:56.320 --> 01:00.240
Now these BGP peers don't have to be directly connected.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

19
00:56.320 --> 01:00.240
Now these BGP peers don't have to be directly connected.

20
01:00.240 --> 01:04.400
For example, R12 and R13, although in this example, they're directly connected

21
01:04.400 --> 01:05.040
via the 10, 12,

22
01:05.040 --> 01:06.960
the 13 network, they don't have to be.

23
01:06.960 --> 01:11.200
We could have, for example, R12 on the 10.20 network over here,

24
01:11.200 --> 01:13.760
and R13 can be on the 10, 30 network over there.

25
01:13.760 --> 01:18.360
But as long as they have reachability using TCP, and the well-known port for BG

26
01:18.360 --> 01:19.040
P to set up the

27
01:19.040 --> 01:21.360
connection is port 179.

28
01:21.360 --> 01:26.720
So unlike an interior gateway routing protocol like OSPF or EIGRP,

29
01:26.720 --> 01:30.000
where those two interior gateway routing protocols have their own layer for
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

30
01:30.000 --> 01:30.720
protocol,

31
01:30.720 --> 01:36.160
BGP operates using layer for protocol TCP, and it connects to the well-known

32
01:36.160 --> 01:37.600
port of 179,

33
01:37.600 --> 01:40.420
which is where a BGP speaker is going to be listening for an incoming

34
01:40.420 --> 01:41.120
connection.

35
01:41.120 --> 01:44.600
And even though it's our topology for the lab environment, I have set up

36
01:44.600 --> 01:46.000
directly connected peers.

37
01:46.000 --> 01:46.800
They don't have to be.

38
01:46.800 --> 01:49.840
As long as they reach ability to the IP addresses of the peer,

39
01:49.840 --> 01:52.640
they can set up a BGP pairing of BGP neighborship.

40
01:52.640 --> 01:56.880
Now regarding BGP peers that we set up, they're going to work with each other.

41
01:56.880 --> 01:57.840
There are two types.

42
01:57.840 --> 02:03.200
There's internal BGP peers and there's external BGP peers.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

42
01:57.840 --> 02:03.200
There's internal BGP peers and there's external BGP peers.

43
02:03.200 --> 02:04.320
And here's the difference.

44
02:04.320 --> 02:07.600
If we have two or three routers that are connected to each other,

45
02:07.600 --> 02:09.440
and they're all in the same autonomous system.

46
02:09.440 --> 02:15.400
For example, R12, peering with R13 and R13, peering with R11 and R11, peering

47
02:15.400 --> 02:16.160
with R12.

48
02:16.160 --> 02:20.160
Because they're all in the same autonomous system, each of these sessions that

49
02:20.160 --> 02:21.920
are being represented by the green lines here,

50
02:21.920 --> 02:27.580
those are going to be referred to as IBGP sessions, or the peers can be called

51
02:27.580 --> 02:28.720
IBGP peers.

52
02:28.720 --> 02:30.000
So these are in the green here.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

53
02:30.000 --> 02:33.940
And again, those are internal BGP peers, because they're all within the same

54
02:33.940 --> 02:34.960
autonomous system.

55
02:34.960 --> 02:39.200
So here for IBGP peers, we'll put same AS.

56
02:39.200 --> 02:44.080
So to finish that out, we'd have an IBGP neighborship here between R32 and R31,

57
02:44.080 --> 02:46.240
because they're both in a autonomous system 30.

58
02:46.240 --> 02:51.440
There'd be internal BGP neighborships between R42, R43 and R41.

59
02:51.440 --> 02:54.640
As shown by these green lines, because all three of those routers are within

60
02:54.640 --> 02:55.600
the same autonomous system,

61
02:55.600 --> 03:00.480
autonomous system 40, and then appear in AS20 for R21 and R22.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

61
02:55.600 --> 03:00.480
autonomous system 40, and then appear in AS20 for R21 and R22.

62
03:00.480 --> 03:04.880
Once they're set up as BGP peers, that would be an example of an internal or IB

63
03:04.880 --> 03:06.080
GP peering session,

64
03:06.080 --> 03:08.240
because they're both in the same autonomous system.

65
03:08.240 --> 03:11.600
Now let's compare and contrast that to an external BGP peer.

66
03:11.600 --> 03:16.160
All it means is that the two routers that have the BGP peering setup,

67
03:16.160 --> 03:19.040
they are in different autonomous systems than each other.

68
03:19.040 --> 03:23.680
And there are several examples here in our topology between R11 and R31,

69
03:23.680 --> 03:28.960
R11 and AS10, R31s in AS30, and as a result, that relationship would be

70
03:28.960 --> 03:30.240
considered an external
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

70
03:28.960 --> 03:30.240
considered an external

71
03:30.240 --> 03:35.120
BGP neighborship, or they can be called external BGP peers.

72
03:35.120 --> 03:36.160
It means the same thing.

73
03:36.160 --> 03:41.760
Also between R31 and R41, because R31 is in AS30, and R41 is in AS40,

74
03:41.760 --> 03:43.920
then also would be an external BGP neighborship.

75
03:43.920 --> 03:49.920
And the same thing for R11 to R21, because R11 is in AS10, and R21 is in AS20.

76
03:49.920 --> 03:54.880
And the same thing here between R21 and R42, because R21 is in the AS20,

77
03:54.880 --> 03:58.480
and R42 is in AS40, because they're in different [garbled],

78
03:58.480 --> 04:00.960
that would also be an external BGP neighborship.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

78
03:58.480 --> 04:00.960
that would also be an external BGP neighborship.

79
04:00.960 --> 04:03.280
So the process would be after we configure our routers,

80
04:03.280 --> 04:06.240
they form BGP sessions to their peers.

81
04:06.240 --> 04:08.800
They start exchanging routing information with their peers.

82
04:08.800 --> 04:11.440
And then once they have all that information, they can then decide,

83
04:11.440 --> 04:14.320
based on all the information they have, which routes are the best,

84
04:14.320 --> 04:16.000
and place those in the routing table.

85
04:16.000 --> 04:20.880
So let's imagine that R11 and R21 have been set up as external BGP neighbors,

86
04:20.880 --> 04:25.920
and R11 is sending an update, a routing update via BGP over to 21.

87
04:25.920 --> 04:29.760
Let's say for example, that we have a route inside of a autonomous system 11,

88
04:29.760 --> 04:34.960
let's say that route is 12.12.12.12, with a /32bit mask,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

88
04:29.760 --> 04:34.960
let's say that route is 12.12.12.12, with a /32bit mask,

89
04:34.960 --> 04:36.880
just as an example for discussion.

90
04:36.880 --> 04:39.200
As that route inside of the autonomous system 10s,

91
04:39.200 --> 04:43.760
and advertised from R11 to an external neighbor over here at R21,

92
04:43.760 --> 04:47.760
the update would say, "Hey, here's the route 12.12.12.12.

93
04:47.760 --> 04:49.840
It has a /32bit mask."

94
04:49.840 --> 04:54.000
And when R21 receives that from the external BGP neighbor R11,

95
04:54.000 --> 04:57.920
R21 is going to believe that the administrative distance for that route is 20,

96
04:57.920 --> 05:02.880
which is pretty low. Compared to IGPs, like OSPF is 110, RIP is 120,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

96
04:57.920 --> 05:02.880
which is pretty low. Compared to IGPs, like OSPF is 110, RIP is 120,

97
05:02.880 --> 05:04.720
EIDRP internal is 90.

98
05:04.720 --> 05:08.650
So that's a pretty low administrative distance from a routing table perspective

99
05:08.650 --> 05:08.880
.

100
05:08.880 --> 05:12.240
However, when a route is shared via internal BGP neighborship,

101
05:12.240 --> 05:16.720
for example, the FAR 12, I've advertised that route over to R13 via BGP,

102
05:16.720 --> 05:19.200
because that's an internal BGP neighborship.

103
05:19.200 --> 05:23.840
R13 is going to assume that the administrative distance for that route

104
05:23.840 --> 05:26.960
learned from an internal BGP neighbor is 200.

105
05:26.960 --> 05:31.440
So here I'll put external AD of 20, and then for the internal,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

105
05:26.960 --> 05:31.440
So here I'll put external AD of 20, and then for the internal,

106
05:31.440 --> 05:35.600
meaning learn via IBGP, we'll put an AD of 200,

107
05:35.600 --> 05:37.600
which is pretty darn high, actually.

108
05:37.600 --> 05:40.000
So that's higher than most of our IGPs.

109
05:40.000 --> 05:44.640
But that's the defaults where the ADs for routes learn via internal BGP peers

110
05:44.640 --> 05:46.960
and routes learned from external BGP peers.

111
05:46.960 --> 05:50.000
Now, in addition to advertising routing information,

112
05:50.000 --> 05:54.800
which is often called NLRI, that's an acronym for network layer reachability

113
05:54.800 --> 05:55.520
information,

114
05:55.520 --> 05:59.040
there's also several attributes that are going to be shared as well.

115
05:59.040 --> 06:01.760
And the reason I'm pointing out attributes right now is because
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

115
05:59.040 --> 06:01.760
And the reason I'm pointing out attributes right now is because

116
06:01.760 --> 06:05.440
it becomes important if a router is receiving multiple routes,

117
06:05.440 --> 06:08.720
it's going to be using some of these attributes to decide which route it should

118
06:08.720 --> 06:10.160
use as the best route.

119
06:10.160 --> 06:12.560
Some of those attributes include the AS path.

120
06:12.560 --> 06:17.680
So, for example, when R1s advertising the route from 12, 12, 12, 12, which came

121
06:17.680 --> 06:18.880
from AS 10,

122
06:18.880 --> 06:22.880
the attribute of AS path would include 10 to indicate which autonomous system

123
06:22.880 --> 06:23.280
is been stored.

124
06:23.280 --> 06:27.120
And then when R21 is advertising that down to, for example,

125
06:27.120 --> 06:31.310
R 42 down here in the time system 40, as far as the attribute is shared down
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

125
06:27.120 --> 06:31.310
R 42 down here in the time system 40, as far as the attribute is shared down

126
06:31.310 --> 06:31.600
here,

127
06:31.600 --> 06:34.320
it would say, "Hey, this was sourced in AS 10.

128
06:34.320 --> 06:36.240
It's also now gone to AS 20."

129
06:36.240 --> 06:38.160
So, as that route is being advertised down here,

130
06:38.160 --> 06:42.960
the network layer reachability information will be 12.12.12.12 still,

131
06:42.960 --> 06:46.000
they slash 32, if that's the actual network.

132
06:46.000 --> 06:50.400
And the AS path attribute would include 10 and 20.

133
06:50.400 --> 06:54.560
The two AS is a two-tomah systems that that routing information has passed

134
06:54.560 --> 06:55.040
through.

135
06:55.040 --> 06:57.600
Ever that same route, as that's being advertised over here,

136
06:57.600 --> 07:00.960
throughout would still be 12, 12, 12, 12, with this slash 32,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

136
06:57.600 --> 07:00.960
throughout would still be 12, 12, 12, 12, with this slash 32,

137
07:00.960 --> 07:05.280
but this time the AS path attribute would include 10 where it was sourced

138
07:05.280 --> 07:07.120
and 20 where it went through.

139
07:07.120 --> 07:09.920
And now because it went through 40, it would include that as well.

140
07:09.920 --> 07:11.840
And that would be part of the advertised

141
07:11.840 --> 07:15.560
a autonomous system path attribute that's being shared in combination with that

142
07:15.560 --> 07:17.920
route via BGP and BGP updates.

143
07:17.920 --> 07:22.230
So, let me clear off a little room and let's talk about some decisions that a B

144
07:22.230 --> 07:24.320
GP-speaking router is going to make

145
07:24.320 --> 07:28.480
if it has two or more sources that it's learning the same route from.

146
07:28.480 --> 07:32.960
Because for example, when R11 is advertising that same 12, 12, 12,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

146
07:28.480 --> 07:32.960
Because for example, when R11 is advertising that same 12, 12, 12,

147
07:32.960 --> 07:36.640
network down to R31, there's the route itself

148
07:36.640 --> 07:39.200
and because R1 is advertising that down to R31.

149
07:39.200 --> 07:42.800
And as R11 advertised that, it's going to indicate that the AS path for this

150
07:42.800 --> 07:43.680
advertisement

151
07:43.680 --> 07:46.000
only includes a ton of system 10 where it was sourced from.

152
07:46.000 --> 07:50.240
So, this router here R31, when it receives the routing information,

153
07:50.240 --> 07:54.560
we're getting the 12, 12, 12, 12 network and it learns it from R11 and it also

154
07:54.560 --> 07:56.240
learns it from R41.

155
07:56.240 --> 07:58.560
It's got to make a decision, we're going to its routing table,

156
07:58.560 --> 08:00.560
regarding which route it's going to use.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

156
07:58.560 --> 08:00.560
regarding which route it's going to use.

157
08:00.560 --> 08:04.480
If it needs to reach that, destination is going to go this way up through R11,

158
08:04.480 --> 08:07.360
or is it going to go this way over here to R41.

159
08:07.360 --> 08:12.300
So, regarding path selection, it can use that attribute AS path as part of the

160
08:12.300 --> 08:13.360
calculation.

161
08:13.360 --> 08:18.200
So, when a router is deciding regarding path selection, the shortest AS path is

162
08:18.200 --> 08:19.200
going to be preferred.

163
08:19.200 --> 08:22.320
Now, that's not the only criteria regarding selecting the best route,

164
08:22.320 --> 08:24.000
and that's also why I didn't put it up here at the top,

165
08:24.000 --> 08:26.560
but it is one of the attributes.

166
08:26.560 --> 08:29.280
So, in this case, if all other settings were equal,

167
08:29.280 --> 08:33.280
R31 would say, "Oh, the AS path to get the 12, 12, 12, 12 is 10 here,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

167
08:29.280 --> 08:33.280
R31 would say, "Oh, the AS path to get the 12, 12, 12, 12 is 10 here,

168
08:33.280 --> 08:37.600
and it's 10, 20, 40 going through R41."

169
08:37.600 --> 08:41.120
And as a result, in this example here, the shortest AS path would be considered

170
08:41.120 --> 08:41.760
the best route,

171
08:41.760 --> 08:43.920
and that's the route that would be put in the routing table,

172
08:43.920 --> 08:47.280
and that's when R31 would use going up to R11,

173
08:47.280 --> 08:51.440
based on the shortest AS path with 10 being less than 10, 20, 40.

174
08:51.440 --> 08:54.560
However, that is not the actual very first thing it looks at,

175
08:54.560 --> 08:58.610
when R31 is trying to make a decision on what is the best path to get to 12, 12

176
08:58.610 --> 08:59.280
, 12, 12.

177
08:59.280 --> 09:03.590
One of the items that's considered first before the shortest AS path is the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

177
08:59.280 --> 09:03.590
One of the items that's considered first before the shortest AS path is the

178
09:03.590 --> 09:04.560
weight.

179
09:04.560 --> 09:06.880
Now, weight is Cisco proprietary.

180
09:06.880 --> 09:09.360
So, if you're working with other vendors,

181
09:09.360 --> 09:12.000
they may not, their gear may not support weight,

182
09:12.000 --> 09:15.680
but in a Cisco environment, weight is the first consideration,

183
09:15.680 --> 09:18.480
when a router is making a decision regarding path selection,

184
09:18.480 --> 09:21.520
the higher the weight, the bigger the number, the better.

185
09:21.520 --> 09:26.800
So, if R31 associated the route that came in from R41 with a weight of 105,

186
09:26.800 --> 09:30.800
and it associated the route that came in from R11 for that 12, 12, 12 network,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

186
09:26.800 --> 09:30.800
and it associated the route that came in from R11 for that 12, 12, 12 network,

187
09:30.800 --> 09:34.560
as 102, the higher the weight would be better.

188
09:34.560 --> 09:38.410
And as a result, R31 would choose the path based on the route that had the

189
09:38.410 --> 09:39.120
highest weight.

190
09:39.120 --> 09:42.480
Now, by default, the weights for the routes that come in are all the same.

191
09:42.480 --> 09:45.760
Now, another item that's looked at is called local preference.

192
09:45.760 --> 09:47.760
And that's used within an autonomous system.

193
09:47.760 --> 09:50.880
So, for example, let's take R43 down here.

194
09:50.880 --> 09:55.920
If it has a route that it's learned from R42 and also learned it from R41,

195
09:55.920 --> 09:57.440
inside the autonomous system,

196
09:57.440 --> 10:01.820
the route that's associated with the greatest or largest local preference would
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

196
09:57.440 --> 10:01.820
the route that's associated with the greatest or largest local preference would

197
10:01.820 --> 10:02.240
be used.

198
10:02.240 --> 10:04.240
So, if R42 is advertising a route,

199
10:04.240 --> 10:08.320
and R43 thought that the local preference for that route was, for example, 105,

200
10:08.320 --> 10:12.350
and R41 was advertising the same route, and R43 associated that route with a

201
10:12.350 --> 10:14.160
local preference of 103,

202
10:14.160 --> 10:16.880
the larger local preference would be preferred.

203
10:16.880 --> 10:19.360
And that's again within the autonomous system.

204
10:19.360 --> 10:23.530
And one other item that Router is going to consider before it looks at the

205
10:23.530 --> 10:23.840
length

206
10:23.840 --> 10:28.320
of the autonomous system paths is, did I source this network myself?

207
10:28.320 --> 10:30.800
Another way of saying that is, is the next top,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

207
10:28.320 --> 10:30.800
Another way of saying that is, is the next top,

208
10:30.800 --> 10:33.040
which is also part of the attribute that they're being sent,

209
10:33.040 --> 10:36.000
is the next top for that route, 0.0.0.0.

210
10:36.000 --> 10:42.630
Meaning, let's imagine R22 is advertising its loopback of 22.22.22.22, with a

211
10:42.630 --> 10:43.440
32-bit mask.

212
10:43.440 --> 10:46.640
As part of the attributes in the BGP table here in R2,

213
10:46.640 --> 10:50.240
it's going to have a next top of 0.0.0.0, effectively saying, "Hey,

214
10:50.240 --> 10:55.040
I'm the person who injected this route or advertised this route inside of BGP."

215
10:55.040 --> 10:58.560
So, if there was another route for 22, 22, 22, 22,

216
10:58.560 --> 11:01.200
that was being advertised that came into R21 here,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

216
10:58.560 --> 11:01.200
that was being advertised that came into R21 here,

217
11:01.200 --> 11:04.080
and then R21 advertised it with the next top of itself.

218
11:04.080 --> 11:08.080
So, it said the next top is 10.21.22.21.

219
11:08.080 --> 11:11.120
Now, R2 has two routes that it knows about.

220
11:11.120 --> 11:14.720
One with the next top of the GIGG 002 here from R21,

221
11:14.720 --> 11:16.880
and one with the next top of 0.0.0.0.

222
11:16.880 --> 11:18.960
And from the decision making process,

223
11:18.960 --> 11:24.020
A route that has the next top of 0.0.0 is going to be identified as the best

224
11:24.020 --> 11:24.480
path.

225
11:24.480 --> 11:28.400
And then we have the shortest AS path as our fourth position right there.

226
11:28.400 --> 11:30.800
And just to reinforce that with our topology,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

226
11:28.400 --> 11:30.800
And just to reinforce that with our topology,

227
11:30.800 --> 11:35.440
let's imagine once again that we're advertising this network 12, 12, 12, 12,

228
11:35.440 --> 11:37.360
and that is being shared here.

229
11:37.360 --> 11:40.480
And then R11 is advertising here and down here.

230
11:40.480 --> 11:42.560
And R31 is advertising here,

231
11:42.560 --> 11:46.800
and R41 is advertising it over to R42 via IBGP,

232
11:46.800 --> 11:49.840
and then R42 is advertising it up here to R21.

233
11:49.840 --> 11:53.440
And then both those routes will be advertised down here to R22.

234
11:53.440 --> 11:54.800
So, as R22 looks at that,

235
11:54.800 --> 11:57.120
if they have the same exact weight, that's the tie,

236
11:57.120 --> 11:58.960
and the local preference is the same for both.

237
11:58.960 --> 12:02.880
And the next hop is not 0.0.0.0, meaning R2 didn't originate that.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

237
11:58.960 --> 12:02.880
And the next hop is not 0.0.0.0, meaning R2 didn't originate that.

238
12:02.880 --> 12:05.040
Then we get to the AS path attribute.

239
12:05.040 --> 12:08.960
And so the one coming in from here would have an AS path attribute of 10.

240
12:08.960 --> 12:15.360
And the one coming in from over here would have 10, 30, 40.

241
12:15.360 --> 12:18.640
Because that's the AS path that it went through as that route was being propag

242
12:18.640 --> 12:18.800
ated

243
12:18.800 --> 12:21.040
and advertised up here to R21.

244
12:21.040 --> 12:23.360
And so as R22, and as well as R21,

245
12:23.360 --> 12:25.200
looking at both those routes,

246
12:25.200 --> 12:28.000
the one that's going to be better based on this shortest AS path,

247
12:28.000 --> 12:30.160
is one that just had to go through AS 10 only,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

247
12:28.000 --> 12:30.160
is one that just had to go through AS 10 only,

248
12:30.160 --> 12:32.000
and the one that didn't have to go through three.

249
12:32.000 --> 12:35.840
Because 10 is less than or shorter than 10, 30, 40.

250
12:35.840 --> 12:39.360
Now, in addition to these four path selection parameters,

251
12:39.360 --> 12:42.320
there's actually a whole bunch more.

252
12:42.320 --> 12:45.040
But for our discussion in this course and in this skill,

253
12:45.040 --> 12:47.280
we're going to go ahead and just consider those first four

254
12:47.280 --> 12:49.200
as the primary ones that we'd want to look at.

255
12:49.200 --> 12:52.000
So as all the routes are propagated and shared,

256
12:52.000 --> 12:56.000
they're going to be put on each of the routers into a IBGP table.

257
12:56.000 --> 12:58.960
You can also refer to that as a rib, a routing information base.

258
12:58.960 --> 13:02.000
And think of the BGP table as everything we've learned.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

258
12:58.960 --> 13:02.000
And think of the BGP table as everything we've learned.

259
13:02.000 --> 13:03.440
So over here in R22,

260
13:03.440 --> 13:05.200
we'd know about the 12 12 12 network,

261
13:05.200 --> 13:06.880
learned from a couple of different sources,

262
13:06.880 --> 13:10.000
and any other routes that have been advertised or shared via BGP.

263
13:10.000 --> 13:13.360
But that doesn't mean that all those routes just automatically

264
13:13.360 --> 13:14.800
make it into the winners table.

265
13:14.800 --> 13:16.080
And when I talk about the winners table,

266
13:16.080 --> 13:18.800
I'm talking about the routing table on a Cisco router.

267
13:18.800 --> 13:20.880
That's the actual routing table that's used.

268
13:20.880 --> 13:22.800
So for example, R22,

269
13:22.800 --> 13:24.720
if it has learned about the 12 12 12 network,

270
13:24.720 --> 13:26.000
a couple different ways,

271
13:26.000 --> 13:27.280
it's going to have one of those,

272
13:27.280 --> 13:30.080
and it's going to put that in the winners table and the routing table.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

272
13:27.280 --> 13:30.080
and it's going to put that in the winners table and the routing table.

273
13:30.080 --> 13:32.880
And then that should show up as a BGP learned route.

274
13:32.880 --> 13:35.200
So R22 could go ahead and start using that route

275
13:35.200 --> 13:36.720
as it forwards real packets.

276
13:36.720 --> 13:39.440
I also want to point out that there's a couple of different ways

277
13:39.440 --> 13:41.200
of configuring BGP.

278
13:41.200 --> 13:43.040
So there's the traditional BGP,

279
13:43.040 --> 13:44.960
and there's also multi protocol.

280
13:44.960 --> 13:46.800
So in this skill and in this set of videos,

281
13:46.800 --> 13:49.360
we're going to focus on the traditional BGP

282
13:49.360 --> 13:52.080
where it supports IPv4 by default.

283
13:52.080 --> 13:56.320
And with multi protocol BGP, it breaks it out into address families.

284
13:56.320 --> 14:00.640
For example, we could have an address family for IPv4 and IPv6
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

284
13:56.320 --> 14:00.640
For example, we could have an address family for IPv4 and IPv6

285
14:00.640 --> 14:04.240
and also for multicast and for other VPN routes and more.

286
14:04.240 --> 14:05.600
And going forward in this set of videos,

287
14:05.600 --> 14:08.080
we're going to focus on traditional BGP.

288
14:08.080 --> 14:10.240
And then as far as address families go,

289
14:10.240 --> 14:12.640
we'll go ahead and save that for another discussion

290
14:12.640 --> 14:15.440
in a separate course in an RC or something equivalent.

291
14:15.440 --> 14:16.720
And before we leave the overview,

292
14:16.720 --> 14:19.920
let me also chat with you about one other consideration

293
14:19.920 --> 14:23.440
that's a really good idea, especially if we are inside

294
14:23.440 --> 14:24.960
of our own autonomous system.

295
14:24.960 --> 14:26.960
And that is to leverage loopbacks.

296
14:26.960 --> 14:30.560
When we set up our pierings between, for example, R13 and R12,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

296
14:26.960 --> 14:30.560
When we set up our pierings between, for example, R13 and R12,

297
14:30.560 --> 14:33.280
which would be an internal BGP neighborship,

298
14:33.280 --> 14:38.800
we could say to R12, "Hey, your pier is at 10.12.13.13."

299
14:38.800 --> 14:40.160
That's this interface address.

300
14:40.160 --> 14:45.040
And on R13, we could say, "Hey, your pier is at 10.12.13.12."

301
14:45.040 --> 14:48.720
And that's all well and good, but what if one of these interfaces fails?

302
14:48.720 --> 14:51.760
If that interface fails, meaning it goes down or has a problem,

303
14:51.760 --> 14:54.000
and that interface IP address is not reachable,

304
14:54.000 --> 14:58.000
we're going to lose that BGP neighborship between R13 and R12.

305
14:58.000 --> 15:00.880
Unless we did something creative like using a loopback.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

305
14:58.000 --> 15:00.880
Unless we did something creative like using a loopback.

306
15:00.880 --> 15:04.400
So by using a loopback, and in each of these autonomous systems,

307
15:04.400 --> 15:06.400
there is an IGP already running.

308
15:06.400 --> 15:10.320
So all the routers via OSPF or whatever IGP they're using,

309
15:10.320 --> 15:12.320
they know how to reach all the internal networks

310
15:12.320 --> 15:15.040
based on the IGP that's in place.

311
15:15.040 --> 15:17.040
So if that was true, and we had this router

312
15:17.040 --> 15:21.280
with the loopback address of 12.12.12.12,

313
15:21.280 --> 15:22.880
if that's the loopback zero address,

314
15:22.880 --> 15:25.200
and over here on R13, if it's loopback zero,

315
15:25.200 --> 15:28.000
is 13.13.13.13.13.

316
15:28.000 --> 15:30.240
Then what we could do is when we set the pairings,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

316
15:28.000 --> 15:30.240
Then what we could do is when we set the pairings,

317
15:30.240 --> 15:30.880
we could say, "You know what?

318
15:30.880 --> 15:35.120
I want to pier with my pier here at this IP address."

319
15:35.120 --> 15:39.480
And on R13, we could say, "I want to pier with the loopback target address here

320
15:39.480 --> 15:39.760
."

321
15:39.760 --> 15:42.320
And that way, even if we lose these interfaces,

322
15:42.320 --> 15:45.200
if we still have another path through the network to get to our pier,

323
15:45.200 --> 15:47.040
we won't lose the BGP neighborship.

324
15:47.040 --> 15:50.320
And that's one of the benefits of using a loopback for peering.

325
15:50.320 --> 15:53.440
So if we do that, we have to specify on the routers,

326
15:53.440 --> 15:57.280
that, "Hey, here's my pier, and I want to source this BGP session

327
15:57.280 --> 16:00.960
from my loopback address as we target the other devices loopback address."
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

327
15:57.280 --> 16:00.960
from my loopback address as we target the other devices loopback address."

328
16:00.960 --> 16:03.040
So with that in mind, in the next video,

329
16:03.040 --> 16:05.600
let's go ahead and begin our configuration

330
16:05.600 --> 16:07.360
of Border Gateway Protocol.

331
16:07.360 --> 16:09.360
I'll see you in the next video in just a moment.