WEBVTT

1
00:00.000 --> 00:08.720
Like all of the other routing protocols other than RIP version 2, BGP maintains

2
00:08.720 --> 00:14.720
neighborhoods with the other routers that it's communicating with using BGP.

3
00:14.720 --> 00:18.080
Now this of course is done for multitude of reasons.

4
00:18.080 --> 00:21.800
One of course is to make sure the other device is still there and reachable and

5
00:21.800 --> 00:22.480
also so we

6
00:22.480 --> 00:27.260
know who we're supposed to be sending information to and so we can manipulate

7
00:27.260 --> 00:28.040
information as

8
00:28.040 --> 00:32.480
we send it to particular neighbors and many other reasons.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

8
00:28.040 --> 00:32.480
we send it to particular neighbors and many other reasons.

9
00:32.480 --> 00:37.950
But like those other routing protocols, BGP also has certain requirements in

10
00:37.950 --> 00:38.600
order for

11
00:38.600 --> 00:42.440
another device to become its BGP neighbor.

12
00:42.440 --> 00:46.120
Our goal in this video is going to be to look at those things.

13
00:46.120 --> 00:49.660
Some of them have to be the same, some of them have to be different, some of

14
00:49.660 --> 00:50.160
them just

15
00:50.160 --> 00:54.220
have to be configured a certain way but again we need to look at the different

16
00:54.220 --> 00:54.920
attributes

17
00:54.920 --> 00:59.680
of the neighborship so that we can troubleshoot if those neighbors are not

18
00:59.680 --> 01:00.920
coming online.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

18
00:59.680 --> 01:00.920
coming online.

19
01:00.920 --> 01:07.310
So let's jump in and take a look at some of the details of our BGP neighbors

20
01:07.310 --> 01:08.160
hips.

21
01:08.160 --> 01:12.840
So let's begin by talking about some of the attributes of BGP neighborships

22
01:12.840 --> 01:13.440
that we need

23
01:13.440 --> 01:15.280
to be aware of.

24
01:15.280 --> 01:19.440
First and foremost, possibly the most important thing for our neighborships is

25
01:19.440 --> 01:20.080
to realize

26
01:20.080 --> 01:27.200
that neighborships happen over TCP specifically port 179.

27
01:27.200 --> 01:35.360
Unlike a lot of other routing protocols such as ISIS, OSPF, EIGRP, OSPF and EIG
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

27
01:27.200 --> 01:35.360
Unlike a lot of other routing protocols such as ISIS, OSPF, EIGRP, OSPF and EIG

28
01:35.360 --> 01:36.680
RP run directly

29
01:36.680 --> 01:38.960
on top of IP.

30
01:38.960 --> 01:43.610
ISIS is a little bit different, we're not going to get into that but BGP doesn

31
01:43.610 --> 01:44.320
't have

32
01:44.320 --> 01:46.760
its own protocol.

33
01:46.760 --> 01:48.440
It runs on TCP.

34
01:48.440 --> 01:51.520
Again, specifically port 179.

35
01:51.520 --> 01:55.290
So what that really means particularly when it comes to troubleshooting is you

36
01:55.290 --> 01:55.720
need to

37
01:55.720 --> 02:01.950
make sure that this is open between the devices, particularly if it has to go
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

37
01:55.720 --> 02:01.950
make sure that this is open between the devices, particularly if it has to go

38
02:01.950 --> 02:03.640
through a firewall

39
02:03.640 --> 02:07.240
or an access control list, anything like that.

40
02:07.240 --> 02:13.130
We need to make sure the TCP port 179 is open and reachable between our

41
02:13.130 --> 02:14.360
neighbors.

42
02:14.360 --> 02:17.440
Next, we of course have authentication.

43
02:17.440 --> 02:23.250
Now, just like with OSPF, authentication is optional here and once again, it

44
02:23.250 --> 02:24.080
can either

45
02:24.080 --> 02:28.400
be MD5 or SHA depending on your version of code.

46
02:28.400 --> 02:34.280
But if you're using authentication, it of course has to match on both sides.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

46
02:28.400 --> 02:34.280
But if you're using authentication, it of course has to match on both sides.

47
02:34.280 --> 02:38.960
So make sure your authentication is the same if it's being used.

48
02:38.960 --> 02:44.200
Something else that BGP does is it does source verification.

49
02:44.200 --> 02:49.880
Now that's sort of a fancy way of saying it simply looks at the source address

50
02:49.880 --> 02:50.320
of the

51
02:50.320 --> 02:55.500
TCP connection coming in and makes sure that that matches up with one of its

52
02:55.500 --> 02:57.480
neighbor statements.

53
02:57.480 --> 03:02.570
So for example, if you were trying to link two routers with their loopback
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

53
02:57.480 --> 03:02.570
So for example, if you were trying to link two routers with their loopback

54
03:02.570 --> 03:03.640
interfaces,

55
03:03.640 --> 03:09.600
you have to use this command update source to tell it that it's sourcing it

56
03:09.600 --> 03:10.160
from in my

57
03:10.160 --> 03:13.800
example, what I just said, from loopback zero.

58
03:13.800 --> 03:19.000
Otherwise, it'll source the TCP packet from its egress interface.

59
03:19.000 --> 03:22.220
And when that gets to the other router, the other router is going to look at

60
03:22.220 --> 03:22.680
its list

61
03:22.680 --> 03:27.390
of neighbors and say, no, you're not on my list of neighbors and essentially

62
03:27.390 --> 03:27.960
hang up

63
03:27.960 --> 03:29.000
on you.

64
03:29.000 --> 03:35.830
What it does specifically if this doesn't match is it sends a TCP reset, which
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

64
03:29.000 --> 03:35.830
What it does specifically if this doesn't match is it sends a TCP reset, which

65
03:35.830 --> 03:37.080
is essentially

66
03:37.080 --> 03:38.080
hanging up on you.

67
03:38.080 --> 03:40.480
It says, you're not on my list of neighbors.

68
03:40.480 --> 03:44.560
Therefore, I will not complete the TCP three way handshake.

69
03:44.560 --> 03:50.910
So if you see a TCP reset in any of your debug, it's almost a certainty that

70
03:50.910 --> 03:51.240
either

71
03:51.240 --> 03:53.760
you're not supposed to be a neighbor at all.

72
03:53.760 --> 03:56.890
Or again, if you're trying to troubleshoot a neighborhood ship that is supposed

73
03:56.890 --> 03:58.400
to exist,

74
03:58.400 --> 04:03.950
it probably means that your update source is not set correctly and you're
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

74
03:58.400 --> 04:03.950
it probably means that your update source is not set correctly and you're

75
04:03.950 --> 04:04.800
sourcing it

76
04:04.800 --> 04:10.160
from an interface that does not match the other router's neighborhood ship.

77
04:10.160 --> 04:14.330
Now something else to keep in mind, our neighborships can fall into one of two

78
04:14.330 --> 04:16.080
major categories,

79
04:16.080 --> 04:19.840
the first of which would be an IBGP peer.

80
04:19.840 --> 04:26.630
An IBGP peer simply means that the peer is in the same AS as the router we're

81
04:26.630 --> 04:27.520
looking

82
04:27.520 --> 04:28.520
at.

83
04:28.520 --> 04:36.210
Now, some of the attributes of an IBGP neighborship, first, it defaults to a
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

83
04:28.520 --> 04:36.210
Now, some of the attributes of an IBGP neighborship, first, it defaults to a

84
04:36.210 --> 04:38.320
TTL of 255.

85
04:38.320 --> 04:43.540
The TTL we're talking about here, of course, is the TTL on this TCP traffic

86
04:43.540 --> 04:44.400
that we're

87
04:44.400 --> 04:46.880
using to form our neighborship.

88
04:46.880 --> 04:49.000
So what does that imply?

89
04:49.000 --> 04:53.640
It implies that your neighbors don't have to be directly connected.

90
04:53.640 --> 04:58.400
They can actually be very far apart, 255 hops.

91
04:58.400 --> 05:02.040
Now of course, the neighbor does still have to be reachable.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

91
04:58.400 --> 05:02.040
Now of course, the neighbor does still have to be reachable.

92
05:02.040 --> 05:05.720
And that's not really something I put on our list here of neighborships, but

93
05:05.720 --> 05:06.400
hopefully

94
05:06.400 --> 05:11.880
it's implied when we said that we had to have reachability of TCP port 179.

95
05:11.880 --> 05:16.660
That does mean that you have to have underlying routing to know how to reach

96
05:16.660 --> 05:17.800
the neighbor.

97
05:17.800 --> 05:22.420
So if I want to appear between loopbacks, I have to have some other route to

98
05:22.420 --> 05:22.880
know how

99
05:22.880 --> 05:24.960
to reach the neighbor's loopback.

100
05:24.960 --> 05:28.040
Usually that's going to come from the IGP.

101
05:28.040 --> 05:35.040
So for example, OSPF or EIGRP, whatever you're running under BGP.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

101
05:28.040 --> 05:35.040
So for example, OSPF or EIGRP, whatever you're running under BGP.

102
05:35.040 --> 05:37.040
Keep in mind on IGP.

103
05:37.040 --> 05:44.000
Neighborships that most of the BGP attributes are not going to be changed.

104
05:44.000 --> 05:49.000
Things like the BGP next hop, the local preference, things like this are not

105
05:49.000 --> 05:50.920
going to be updated

106
05:50.920 --> 05:53.600
as they're passed between the neighbors.

107
05:53.600 --> 05:58.580
And as we already said, because it's 255, these neighbors do not have to be

108
05:58.580 --> 05:59.280
directly

109
05:59.280 --> 06:00.520
connected.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

109
05:59.280 --> 06:00.520
connected.

110
06:00.520 --> 06:02.360
The only reason we're saying that specifically is the contrast that of course

111
06:02.360 --> 06:06.600
to E BGP with

112
06:06.600 --> 06:09.960
E BGP or external BGP neighbors.

113
06:09.960 --> 06:14.440
The peer in this case, of course, is going to be in a different AS.

114
06:14.440 --> 06:20.640
And by the way, that's all we have to do to configure whether it's IBGP or E B

115
06:20.640 --> 06:21.160
GP.

116
06:21.160 --> 06:25.590
When we're configuring the neighborship, we simply list the neighbors AS and

117
06:25.590 --> 06:26.400
that AS

118
06:26.400 --> 06:29.760
either matches our AS in which case, the router knows.

119
06:29.760 --> 06:32.200
It's an IBGP connection.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

119
06:29.760 --> 06:32.200
It's an IBGP connection.

120
06:32.200 --> 06:38.320
Or if it's a different AS, the router then knows that it's an E BGP connection.

121
06:38.320 --> 06:42.450
There's no command we put in specifically to tell it which type of neighborship

122
06:42.450 --> 06:43.680
it is.

123
06:43.680 --> 06:49.950
It is simply implied by the fact that if I say router BGP 100, and then I say

124
06:49.950 --> 06:50.760
neighbor

125
06:50.760 --> 06:57.050
x dot x dot x dot x remote AS 200, it knows that they're in different AS's and

126
06:57.050 --> 06:58.040
therefore

127
06:58.040 --> 07:00.640
it's going to be E BGP.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

127
06:58.040 --> 07:00.640
it's going to be E BGP.

128
07:00.640 --> 07:06.110
Now another attribute of this is it's going to default to a TTL of one, which

129
07:06.110 --> 07:07.200
again really

130
07:07.200 --> 07:11.160
does imply that the neighbors have to be directly connected.

131
07:11.160 --> 07:13.560
Now, of course, we have some exceptions to that down here.

132
07:13.560 --> 07:15.280
We'll get to in just a moment.

133
07:15.280 --> 07:21.230
But before we do, understand that most of our BGP attributes are in fact

134
07:21.230 --> 07:22.280
updated.

135
07:22.280 --> 07:24.440
So we will update the next hop.

136
07:24.440 --> 07:28.000
We will prepend our AS number, things like this.

137
07:28.000 --> 07:32.320
So most of the change happens on E BGP neighborships.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

137
07:28.000 --> 07:32.320
So most of the change happens on E BGP neighborships.

138
07:32.320 --> 07:38.430
And again, most of the attributes are left unchanged when we send the update to

139
07:38.430 --> 07:38.880
IBGP

140
07:38.880 --> 07:39.880
neighbors.

141
07:39.880 --> 07:45.400
Now, if you do need to connect E BGP neighbors that are not directly connected,

142
07:45.400 --> 07:45.960
it really

143
07:45.960 --> 07:47.440
depends on what you're trying to do.

144
07:47.440 --> 07:50.120
There's sort of two ways to go here.

145
07:50.120 --> 07:55.240
If the neighbors are really going to be more than one hop away, then you can

146
07:55.240 --> 07:56.280
use this command

147
07:56.280 --> 07:59.000
here, E BGP multi hop.

148
07:59.000 --> 08:01.880
And the X, of course, will be replaced by a number.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

148
07:59.000 --> 08:01.880
And the X, of course, will be replaced by a number.

149
08:01.880 --> 08:07.560
And this number would update this TTL to whatever value you want it to be.

150
08:07.560 --> 08:13.880
However, if the neighbors are directly connected, but you just want to use a

151
08:13.880 --> 08:15.560
different address.

152
08:15.560 --> 08:18.400
So maybe a loopback interface.

153
08:18.400 --> 08:22.680
You can instead do a disable connected check.

154
08:22.680 --> 08:26.390
This means that the addressing of the neighbor doesn't have to match your

155
08:26.390 --> 08:27.520
directly connected

156
08:27.520 --> 08:28.960
interface.

157
08:28.960 --> 08:35.850
So I could hook two E BGP routers together, put in routing, maybe static
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

157
08:28.960 --> 08:35.850
So I could hook two E BGP routers together, put in routing, maybe static

158
08:35.850 --> 08:37.360
routing, so that

159
08:37.360 --> 08:41.000
I can reach my neighbors loopback interface.

160
08:41.000 --> 08:45.410
And then I can just disable connected check to allow that neighbor ship to come

161
08:45.410 --> 08:45.880
up.

162
08:45.880 --> 08:49.960
Now you could also just do E BGP multi hop to.

163
08:49.960 --> 08:55.710
If you did that, that would be fine as well, because E BGP multi hop also dis

164
08:55.710 --> 08:56.360
ables the

165
08:56.360 --> 08:58.160
connected check.

166
08:58.160 --> 09:02.720
So you sort of have two options there for non directly connected E BGP
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

166
08:58.160 --> 09:02.720
So you sort of have two options there for non directly connected E BGP

167
09:02.720 --> 09:03.720
neighbors.

168
09:03.720 --> 09:07.680
Again, it really just depends how far away they are.

169
09:07.680 --> 09:11.900
Most people tend to use E BGP multi hop, even if you're just trying to appear

170
09:11.900 --> 09:12.440
between

171
09:12.440 --> 09:15.840
loopbacks, but it's not strictly necessary.

172
09:15.840 --> 09:19.530
Now when we're talking about neighborships, it's going to be important to

173
09:19.530 --> 09:19.880
discuss the

174
09:19.880 --> 09:24.960
BGP message types as well as different neighbor states.

175
09:24.960 --> 09:27.560
So let's start with the BGP message types.

176
09:27.560 --> 09:29.040
There are four.

177
09:29.040 --> 09:30.760
First we have the open message.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

177
09:29.040 --> 09:30.760
First we have the open message.

178
09:30.760 --> 09:36.000
This of course is just when we're sending essentially a high, how are you doing

179
09:36.000 --> 09:36.120
here

180
09:36.120 --> 09:38.360
are my BGP parameters?

181
09:38.360 --> 09:40.120
Are these going to match up?

182
09:40.120 --> 09:41.760
And then the other side sends back an open.

183
09:41.760 --> 09:43.320
Yes, they do.

184
09:43.320 --> 09:45.720
And we agree that we can be neighbors.

185
09:45.720 --> 09:50.400
So open is for the initial communication between the BGP routers.

186
09:50.400 --> 09:52.400
Then you have update.

187
09:52.400 --> 09:55.280
Update is what carries the actual BGP updates.

188
09:55.280 --> 09:59.820
So again, you could go so far as to say this is the primary message type or the

189
09:59.820 --> 10:00.800
workhorse
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

189
09:59.820 --> 10:00.800
workhorse

190
10:00.800 --> 10:02.480
of the message types.

191
10:02.480 --> 10:05.400
This is what's going to carry the bulk of the information.

192
10:05.400 --> 10:10.500
You have keep alive, which of course is really just sort of a housekeeping type

193
10:10.500 --> 10:11.360
message.

194
10:11.360 --> 10:15.980
The default is we send this every 60 seconds, those timers of course can be

195
10:15.980 --> 10:17.120
adjusted, but

196
10:17.120 --> 10:22.330
this is simply to make sure the other end of the connection is still responding

197
10:22.330 --> 10:22.440
.

198
10:22.440 --> 10:24.360
Then you have a notification.

199
10:24.360 --> 10:30.540
A notification is basically an error message where you're tearing down the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

199
10:24.360 --> 10:30.540
A notification is basically an error message where you're tearing down the

200
10:30.540 --> 10:31.920
connection.

201
10:31.920 --> 10:35.570
Something went wrong and it could even be something as simple as the

202
10:35.570 --> 10:36.640
administrator did

203
10:36.640 --> 10:39.440
a hard reset on the neighborhood.

204
10:39.440 --> 10:44.280
But for some reason, this router wants to tear down the neighborship.

205
10:44.280 --> 10:48.470
I will send a notification message to the other side, essentially telling them

206
10:48.470 --> 10:48.880
that I'm

207
10:48.880 --> 10:50.440
hanging up on them.

208
10:50.440 --> 10:53.520
So notification is basically going to be the end of the neighborship.

209
10:53.520 --> 10:56.920
Now that doesn't mean the neighborship's not going to just come right back up.

210
10:56.920 --> 10:58.440
It certainly could.

211
10:58.440 --> 11:02.680
But notification is used to tear down the neighborship.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

211
10:58.440 --> 11:02.680
But notification is used to tear down the neighborship.

212
11:02.680 --> 11:06.420
And speaking of that neighborship, of course, there are several different BGP

213
11:06.420 --> 11:07.000
neighbors

214
11:07.000 --> 11:08.000
states.

215
11:08.000 --> 11:10.040
First is idle.

216
11:10.040 --> 11:15.240
In the idle state, it means we haven't even started to try.

217
11:15.240 --> 11:17.120
We have not sent an open message.

218
11:17.120 --> 11:23.320
We have not even done a TCP three way handshake to try to open the connection.

219
11:23.320 --> 11:27.190
We could be stuck in this state because maybe we don't have a route to know how

220
11:27.190 --> 11:27.760
to get to

221
11:27.760 --> 11:31.780
the neighbor and your router is going to sit there going, well, I see you put
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

221
11:27.760 --> 11:31.780
the neighbor and your router is going to sit there going, well, I see you put

222
11:31.780 --> 11:32.280
in a neighbor

223
11:32.280 --> 11:34.480
statement, but I have no route to get to that.

224
11:34.480 --> 11:36.600
So I can't even start.

225
11:36.600 --> 11:39.560
So clearly it's going to start off in the idle state.

226
11:39.560 --> 11:44.980
And since BGP, let's be honest, isn't super fast and honestly it's not meant to

227
11:44.980 --> 11:45.520
be, you

228
11:45.520 --> 11:51.480
could if you do a show IPBGP summary, you could catch it in the idle state.

229
11:51.480 --> 11:53.720
But it certainly should not stay there.

230
11:53.720 --> 11:57.620
What it should do is after it creates the TCP three way handshake, it should

231
11:57.620 --> 11:58.440
then go to

232
11:58.440 --> 12:00.120
connect.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

232
11:58.440 --> 12:00.120
connect.

233
12:00.120 --> 12:04.100
Connect means we have established our TCP three way handshake and we are now

234
12:04.100 --> 12:04.600
ready to

235
12:04.600 --> 12:08.480
begin, we will go to the active state.

236
12:08.480 --> 12:15.210
Active state means we are ready to send open messages on our show IPBGP summary

237
12:15.210 --> 12:15.280
.

238
12:15.280 --> 12:20.280
It would be actually quite common to see a BGP neighbor stuck in active.

239
12:20.280 --> 12:24.430
If maybe they're not configured to talk to you, you're not configured to be one

240
12:24.430 --> 12:25.160
of their

241
12:25.160 --> 12:26.160
neighbors.

242
12:26.160 --> 12:27.760
You might get stuck in active.

243
12:27.760 --> 12:32.070
You might see it bouncing between active idle connect active idle connect, you
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

243
12:27.760 --> 12:32.070
You might see it bouncing between active idle connect active idle connect, you

244
12:32.070 --> 12:32.480
know, going

245
12:32.480 --> 12:36.640
through the different phases, trying to form that neighborship.

246
12:36.640 --> 12:41.050
If however, we do get our TCP three way connection all the way up and running,

247
12:41.050 --> 12:41.800
we will then

248
12:41.800 --> 12:46.590
send our open message as long as everything is correct in the open message, you

249
12:46.590 --> 12:47.120
will get

250
12:47.120 --> 12:52.160
an open message back at which point you go to open confirm.

251
12:52.160 --> 12:56.120
Once that's done, we will begin to exchange update messages.

252
12:56.120 --> 13:00.800
And once everything is complete, you will then see established.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

252
12:56.120 --> 13:00.800
And once everything is complete, you will then see established.

253
13:00.800 --> 13:06.520
Now one quick thing to note about established, we keep talking about the show

254
13:06.520 --> 13:07.880
IPBGP summary.

255
13:07.880 --> 13:11.000
In fact, let's take a look at it real quick.

256
13:11.000 --> 13:17.080
So just as an example here on router seven, let's do a show IPBGP summary.

257
13:17.080 --> 13:23.360
Notice here under the state and prefix, it doesn't say established.

258
13:23.360 --> 13:27.360
It simply says how many prefixes we've received.

259
13:27.360 --> 13:32.730
So in this case, I have received eight prefixes from this particular neighbor,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

259
13:27.360 --> 13:32.730
So in this case, I have received eight prefixes from this particular neighbor,

260
13:32.730 --> 13:33.760
which happens

261
13:33.760 --> 13:35.680
to be router one.

262
13:35.680 --> 13:41.060
And we can see here on the up down timer that it's been up for two days and 16

263
13:41.060 --> 13:41.960
hours.

264
13:41.960 --> 13:47.970
The assumption here is that if this is a number, even if that number is zero,

265
13:47.970 --> 13:48.760
that the state

266
13:48.760 --> 13:53.970
must be established because I wouldn't be expecting any prefixes unless the

267
13:53.970 --> 13:54.720
state was

268
13:54.720 --> 13:56.160
established.

269
13:56.160 --> 13:59.680
So if the state is established, you'll never see it listed here.

270
13:59.680 --> 14:00.680
It's implied.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

270
13:59.680 --> 14:00.680
It's implied.

271
14:00.680 --> 14:05.380
Now, of course, you can still see it if you do a show IPBGP neighbor and then

272
14:05.380 --> 14:05.960
ask for

273
14:05.960 --> 14:08.320
that particular neighbor.

274
14:08.320 --> 14:12.280
Since this is my only neighbor, I really didn't need to specify it.

275
14:12.280 --> 14:17.270
But if we look here at the top of the output, we can see here that it says the

276
14:17.270 --> 14:17.760
state is

277
14:17.760 --> 14:19.480
established.

278
14:19.480 --> 14:24.960
So again, you can see it on the show IPBGP neighbor, but not on the show IPBGP

279
14:24.960 --> 14:25.800
summary.

280
14:25.800 --> 14:29.080
It just shows a number if the state is established.

281
14:29.080 --> 14:33.210
And again, that number may in fact be zero just because we're neighbors doesn't
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

281
14:29.080 --> 14:33.210
And again, that number may in fact be zero just because we're neighbors doesn't

282
14:33.210 --> 14:34.000
necessarily

283
14:34.000 --> 14:37.080
mean that you have any prefixes to send me.

284
14:37.080 --> 14:43.920
So zero still means established in the state slash prefix received column.

285
14:43.920 --> 14:49.460
So to wrap up, let's talk about some of the common issues that happen with BGP

286
14:49.460 --> 14:50.680
neighbors.

287
14:50.680 --> 14:55.400
First and foremost, how about configuring the neighbor with the wrong IP

288
14:55.400 --> 14:56.360
address?

289
14:56.360 --> 15:00.480
This is creating a TCP neighbor ship between these two devices.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

289
14:56.360 --> 15:00.480
This is creating a TCP neighbor ship between these two devices.

290
15:00.480 --> 15:04.630
If you try to put the wrong IP address in, clearly, they're not going to be

291
15:04.630 --> 15:05.160
able to

292
15:05.160 --> 15:06.360
neighbor up.

293
15:06.360 --> 15:10.120
This is a manual process in BGP.

294
15:10.120 --> 15:14.930
While you're configuring that peer, you could also configure it with the wrong

295
15:14.930 --> 15:16.680
peer AS number.

296
15:16.680 --> 15:22.090
If on my neighbor statement, where I'm configuring the remote AS, I say remote

297
15:22.090 --> 15:23.680
AS 100, but the

298
15:23.680 --> 15:29.360
other router is actually running AS 200, this neighbor ship is not going to

299
15:29.360 --> 15:30.040
form.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

299
15:29.360 --> 15:30.040
form.

300
15:30.040 --> 15:34.200
Now once again, it doesn't have to match our AS number.

301
15:34.200 --> 15:38.080
If the neighbor's AS number is different than ours, that simply means that it's

302
15:38.080 --> 15:39.960
eBGP.

303
15:39.960 --> 15:45.650
But to be clear, what we're saying here is if I say the other routers AS is 200

304
15:45.650 --> 15:46.280
, then

305
15:46.280 --> 15:51.920
the other router also has to say that their AS is 200.

306
15:51.920 --> 15:57.600
And if my AS is 100, then they better say that my remote AS is 100.

307
15:57.600 --> 16:01.680
We have to list the peers AS number correctly.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

307
15:57.600 --> 16:01.680
We have to list the peers AS number correctly.

308
16:01.680 --> 16:05.360
Now these last two, we did sort of already discuss where you might have a

309
16:05.360 --> 16:07.360
transport issue.

310
16:07.360 --> 16:14.150
Remember you have to have routing to the remote address and TCP port 179 has to

311
16:14.150 --> 16:14.840
be open to

312
16:14.840 --> 16:16.520
that remote address.

313
16:16.520 --> 16:21.720
We can't have an access list or firewall or something else in between these two

314
16:21.720 --> 16:22.720
devices,

315
16:22.720 --> 16:28.000
blocking TCP port 179 or blocking communication in general.

316
16:28.000 --> 16:32.180
And of course, if authentication is configured, then it's going to have to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

316
16:28.000 --> 16:32.180
And of course, if authentication is configured, then it's going to have to

317
16:32.180 --> 16:33.720
match on both sides

318
16:33.720 --> 16:36.240
or the neighbor ship will not form.

319
16:36.240 --> 16:41.200
Again, hopefully that makes sense because otherwise authentication wouldn't be

320
16:41.200 --> 16:41.560
much

321
16:41.560 --> 16:42.560
use.

322
16:42.560 --> 16:48.480
The purpose of the authentication is to make sure that we don't get unwanted

323
16:48.480 --> 16:48.920
neighbors.

324
16:48.920 --> 16:53.800
So in this video, we talked about some of the aspects and attributes of BGP

325
16:53.800 --> 16:54.800
neighborships

326
16:54.800 --> 17:00.040
and some of the things that can prevent BGP neighborships from forming.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

326
16:54.800 --> 17:00.040
and some of the things that can prevent BGP neighborships from forming.

327
17:00.040 --> 17:05.470
The next big thing we have to talk about is the BGP path selection process so

328
17:05.470 --> 17:05.720
that we

329
17:05.720 --> 17:11.280
understand how different attributes affect our BGP path selection.

330
17:11.280 --> 17:13.280
So let's do that in the next video.

331
17:13.280 --> 17:23.280
[BLANK_AUDIO]