WEBVTT

1
00:00.000 --> 00:05.520
So as we jump in, let's just take a look at this diagram real quickly.

2
00:05.520 --> 00:10.560
Notice that we have CE1 here in the middle, which is acting as our customer

3
00:10.560 --> 00:11.640
edge.

4
00:11.640 --> 00:14.180
This is the router that we're going to be focusing on.

5
00:14.180 --> 00:20.060
This is the one that's running BGP and getting routes from service provider one

6
00:20.060 --> 00:20.080
.

7
00:20.080 --> 00:23.760
Now service provider one is just acting like our service provider.

8
00:23.760 --> 00:27.720
So it's just sending us some BGP routes and such.

9
00:27.720 --> 00:35.250
And for the switch one side, this is literally just to have gigabit 2 be up on
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

9
00:27.720 --> 00:35.250
And for the switch one side, this is literally just to have gigabit 2 be up on

10
00:35.250 --> 00:36.280
CE1 so that

11
00:36.280 --> 00:40.480
CE1 can inject that route into BGP.

12
00:40.480 --> 00:42.920
So this is just a very simple topology.

13
00:42.920 --> 00:46.930
And believe me when I say that all of the routes we're going to see showing up

14
00:46.930 --> 00:48.080
on CE1

15
00:48.080 --> 00:51.670
are literally just coming from a bunch of loopbacks that are on service

16
00:51.670 --> 00:52.560
provider one.

17
00:52.560 --> 00:56.120
It's just so we can see how BGP works a little bit here.

18
00:56.120 --> 01:01.040
So that said, let's go ahead and jump in to CE1.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

18
00:56.120 --> 01:01.040
So that said, let's go ahead and jump in to CE1.

19
01:01.040 --> 01:05.920
So the first thing we'll look at here on CE1 is simply a show IP route.

20
01:05.920 --> 01:09.400
And looking over the routing table, there's a few things we see.

21
01:09.400 --> 01:12.000
First we do in fact have a default route.

22
01:12.000 --> 01:18.040
We see that our gateway of last resort is set to 204.186.19.1.

23
01:18.040 --> 01:23.880
But notice that the route for that is actually coming from BGP.

24
01:23.880 --> 01:28.630
And we have some other BGP prefixes that we've learned here a little bit

25
01:28.630 --> 01:29.760
further down.

26
01:29.760 --> 01:34.680
So we are in fact running BGP, we're learning routes through BGP.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

26
01:29.760 --> 01:34.680
So we are in fact running BGP, we're learning routes through BGP.

27
01:34.680 --> 01:40.320
Now we'll be focusing more in on troubleshooting BGP a bit later in this course

28
01:40.320 --> 01:40.400
.

29
01:40.400 --> 01:45.180
But for now, let's just take a look at some good commands for verifying what B

30
01:45.180 --> 01:46.160
GP is actually

31
01:46.160 --> 01:47.680
doing.

32
01:47.680 --> 01:52.640
Probably one of the first go to commands would be show IP BGP summary.

33
01:52.640 --> 01:57.400
This will show you a quick summary of your current neighbors, what version you

34
01:57.400 --> 01:58.440
're running,

35
01:58.440 --> 02:03.210
what that neighbor's a yes number is, how many messages have been sent and
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

35
01:58.440 --> 02:03.210
what that neighbor's a yes number is, how many messages have been sent and

36
02:03.210 --> 02:03.960
received,

37
02:03.960 --> 02:09.500
the current BGP table version that has been exchanged with that neighbor, any

38
02:09.500 --> 02:10.160
packets

39
02:10.160 --> 02:15.440
waiting in the input or output queue, how long this particular neighbor has

40
02:15.440 --> 02:17.520
been up or down,

41
02:17.520 --> 02:21.880
and how many prefixes we've learned from that neighbor.

42
02:21.880 --> 02:26.100
And also not to jump over it, there's a lot of good information up here at the

43
02:26.100 --> 02:26.600
top as

44
02:26.600 --> 02:31.800
well, where it tells us what our current BGP router ID is, what our local AS
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

44
02:26.600 --> 02:31.800
well, where it tells us what our current BGP router ID is, what our local AS

45
02:31.800 --> 02:32.440
number

46
02:32.440 --> 02:37.730
is, your local BGP table version and the version that has been sent to the main

47
02:37.730 --> 02:38.400
routing

48
02:38.400 --> 02:39.400
table.

49
02:39.400 --> 02:41.940
These of course should normally be the same.

50
02:41.940 --> 02:45.670
We can see how many entries and how much RAM we're taking, if there's any route

51
02:45.670 --> 02:46.000
maps

52
02:46.000 --> 02:48.880
or AS path entries being used.

53
02:48.880 --> 02:54.480
So we can see here a lot of really good information about our BGP process.

54
02:54.480 --> 02:58.130
Of course, if we want any more detailed information about this particular

55
02:58.130 --> 02:59.400
neighbor, we could say

56
02:59.400 --> 03:02.200
show IP BGP neighbor.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

56
02:59.400 --> 03:02.200
show IP BGP neighbor.

57
03:02.200 --> 03:04.920
Now for this, we may have to scroll back up depending on what our terminal

58
03:04.920 --> 03:05.320
length is

59
03:05.320 --> 03:11.140
set to, but we can see here, this gives us a lot of information and it's a lot

60
03:11.140 --> 03:11.800
more than

61
03:11.800 --> 03:16.120
we're going to jump into right now, but it will tell us the neighbor's address,

62
03:16.120 --> 03:16.640
the remote

63
03:16.640 --> 03:23.290
AS number, its router ID, how long it has been up in its current state, the

64
03:23.290 --> 03:24.000
current hold

65
03:24.000 --> 03:28.150
time and keep a live timer for the neighbor ship, then we have some information

66
03:28.150 --> 03:28.560
about

67
03:28.560 --> 03:33.430
the neighbor's capabilities, like does it support route refresh, 4 octet ASN
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

67
03:28.560 --> 03:33.430
the neighbor's capabilities, like does it support route refresh, 4 octet ASN

68
03:33.430 --> 03:34.000
numbers

69
03:34.000 --> 03:35.720
and so on.

70
03:35.720 --> 03:39.030
So like I said, there's a lot of information here, we're not going to dig into

71
03:39.030 --> 03:39.600
it all right

72
03:39.600 --> 03:44.320
now, but as you can see, all sorts of information about how many prefixes have

73
03:44.320 --> 03:45.440
been exchanged,

74
03:45.440 --> 03:49.240
the current table version with that particular neighbor and so on.

75
03:49.240 --> 03:54.960
Lots and lots of information, very, very useful command for troubleshooting.

76
03:54.960 --> 04:01.160
Now a show IP BGP just by itself will show us just the BGP table.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

76
03:54.960 --> 04:01.160
Now a show IP BGP just by itself will show us just the BGP table.

77
04:01.160 --> 04:05.200
Now again, there's a legend up here at the top to tell us our status codes, but

78
04:05.200 --> 04:05.440
let's

79
04:05.440 --> 04:07.760
just go ahead and look down here at the bottom.

80
04:07.760 --> 04:14.790
These are all of the prefixes that we are either learning or advertising into B

81
04:14.790 --> 04:15.400
GP.

82
04:15.400 --> 04:18.640
For example, we see here we're learning our default route.

83
04:18.640 --> 04:23.580
We also see the other, in this case, five prefixes that we're also learning

84
04:23.580 --> 04:24.360
from that

85
04:24.360 --> 04:27.920
neighbor 204.186.19.1.

86
04:27.920 --> 04:30.700
Now we can't just tell by looking at this that that's the neighbor we're
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

86
04:27.920 --> 04:30.700
Now we can't just tell by looking at this that that's the neighbor we're

87
04:30.700 --> 04:31.320
learning it

88
04:31.320 --> 04:35.160
from by the way, that's actually the next hop.

89
04:35.160 --> 04:41.480
Now since this is an E BGP or an external BGP session, usually the next hop is

90
04:41.480 --> 04:41.960
going

91
04:41.960 --> 04:43.920
to be the neighbor's address.

92
04:43.920 --> 04:47.020
There are exceptions and a lot of things we're not going to get into right at

93
04:47.020 --> 04:48.600
this moment,

94
04:48.600 --> 04:53.400
but in this case, the next hop does happen to match the neighbor's address.

95
04:53.400 --> 04:56.120
Just be aware that that's not always the case.

96
04:56.120 --> 04:59.440
We also have the metric or what Cisco calls the med.

97
04:59.440 --> 05:03.870
We have the local preference, which in this case is not configured on any of
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

97
04:59.440 --> 05:03.870
We have the local preference, which in this case is not configured on any of

98
05:03.870 --> 05:04.960
these prefixes.

99
05:04.960 --> 05:06.760
Then we see the weight.

100
05:06.760 --> 05:11.200
Now we're not going to get a lot into the BGP attributes right now either.

101
05:11.200 --> 05:14.280
Weight is a Cisco proprietary attribute.

102
05:14.280 --> 05:19.290
The default behavior for weight is that the weight is zero on all prefixes that

103
05:19.290 --> 05:19.880
have been

104
05:19.880 --> 05:27.240
learned and it's set to 3278 for locally injected prefixes.

105
05:27.240 --> 05:35.000
So here we can see that the 10.10.10.0 actually has a next hop of 0.0.0.0 and a
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

105
05:27.240 --> 05:35.000
So here we can see that the 10.10.10.0 actually has a next hop of 0.0.0.0 and a

106
05:35.000 --> 05:35.920
weight of

107
05:35.920 --> 05:38.360
32, 768.

108
05:38.360 --> 05:43.380
Both of those things, the next hop and the weight are indicators that this is a

109
05:43.380 --> 05:44.640
locally injected

110
05:44.640 --> 05:46.320
route.

111
05:46.320 --> 05:49.600
Notice that the AS path is also empty.

112
05:49.600 --> 05:53.960
That's also usually a pretty good indicator that it's locally injected.

113
05:53.960 --> 05:56.760
The other ones notice they all have an AS path.

114
05:56.760 --> 06:01.350
That AS path has been artificially modified to make the network look bigger
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

114
05:56.760 --> 06:01.350
That AS path has been artificially modified to make the network look bigger

115
06:01.350 --> 06:02.240
than it is.

116
06:02.240 --> 06:07.320
These are all actually coming from our neighboring AS 3222 one.

117
06:07.320 --> 06:11.100
And again, some of these have been manipulated to look like they're coming from

118
06:11.100 --> 06:11.560
a little

119
06:11.560 --> 06:13.080
further away.

120
06:13.080 --> 06:17.080
But nonetheless, this is what the BGP table looks like.

121
06:17.080 --> 06:21.390
If you do a show IP route and filter it by BGP, this will actually simply

122
06:21.390 --> 06:22.120
filter the

123
06:22.120 --> 06:26.990
route table to show just the BGP routes, the user of course, all the routes

124
06:26.990 --> 06:27.520
that have

125
06:27.520 --> 06:32.500
been chosen as best from the BGP table and have not lost the administrative
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

125
06:27.520 --> 06:32.500
been chosen as best from the BGP table and have not lost the administrative

126
06:32.500 --> 06:33.240
distance

127
06:33.240 --> 06:37.440
battle and have therefore been placed into the route table.

128
06:37.440 --> 06:42.640
Now a few other commands that can be incredibly useful, particularly if any

129
06:42.640 --> 06:44.080
form of BGP filtering

130
06:44.080 --> 06:47.920
is involved, either inbound or outbound.

131
06:47.920 --> 06:50.280
Let's take a look at inbound first.

132
06:50.280 --> 06:55.280
You can actually see the routes that have been received versus the ones that

133
06:55.280 --> 06:56.160
have made it

134
06:56.160 --> 07:02.440
into the BGP table if you have soft inbound reconfiguration set.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

134
06:56.160 --> 07:02.440
into the BGP table if you have soft inbound reconfiguration set.

135
07:02.440 --> 07:08.020
The command to do that is show IPBGP neighbor, put in the neighbor's address,

136
07:08.020 --> 07:08.880
and then you

137
07:08.880 --> 07:11.000
say received routes.

138
07:11.000 --> 07:16.220
Now in this case, I can't do that because I don't have soft reconfiguration in

139
07:16.220 --> 07:17.680
bound enabled.

140
07:17.680 --> 07:22.480
However, if you want to turn that feature on, it's fairly easy to do.

141
07:22.480 --> 07:25.330
And by the way, when you're going into configuration, a little trick you can do

142
07:25.330 --> 07:26.200
, if you don't remember

143
07:26.200 --> 07:30.960
your local AS number, you can only run BGP once on a router.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

143
07:26.200 --> 07:30.960
your local AS number, you can only run BGP once on a router.

144
07:30.960 --> 07:34.880
So I'll usually just say router BGP one, it'll say no, no, no, you can't do

145
07:34.880 --> 07:35.400
that because

146
07:35.400 --> 07:39.760
it's already running as 65001 and you say, okay, thank you very much.

147
07:39.760 --> 07:43.360
I couldn't remember what it was, 65001.

148
07:43.360 --> 07:46.760
Now truthfully, this probably won't happen if you're working on your own

149
07:46.760 --> 07:47.400
network.

150
07:47.400 --> 07:49.640
You probably know your own AS number.

151
07:49.640 --> 07:53.040
But I find that useful as a consultant when I'm going into a lot of different

152
07:53.040 --> 07:53.600
networks

153
07:53.600 --> 07:57.560
and I'm on a customer's network and I'm like, what's the local AS number again?

154
07:57.560 --> 08:00.880
Well, you can just find out quick and easy just like that.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

154
07:57.560 --> 08:00.880
Well, you can just find out quick and easy just like that.

155
08:00.880 --> 08:05.500
But in any case, what we want to say is neighbor, we put in the neighbor's

156
08:05.500 --> 08:06.480
address, and you

157
08:06.480 --> 08:08.840
say soft reconfiguration.

158
08:08.840 --> 08:13.080
And they actually make you say inbound, even though it's the only choice.

159
08:13.080 --> 08:20.400
So we just say in, we'll exit our configuration and we'll do our command again.

160
08:20.400 --> 08:25.230
Now as you can see here, this now shows us all of the routes that we have

161
08:25.230 --> 08:26.360
received from

162
08:26.360 --> 08:27.920
that neighbor.

163
08:27.920 --> 08:34.710
This can be very useful if we see the routes here, but then we say show IPBGP
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

163
08:27.920 --> 08:34.710
This can be very useful if we see the routes here, but then we say show IPBGP

164
08:34.710 --> 08:35.240
and one of

165
08:35.240 --> 08:36.880
them's missing.

166
08:36.880 --> 08:40.380
It would indicate that we're receiving the network from the neighbor, but yet

167
08:40.380 --> 08:40.920
it's not

168
08:40.920 --> 08:47.360
making it into our own table, which means our own filtering is not working.

169
08:47.360 --> 08:50.240
So these are some good commands to keep in mind.

170
08:50.240 --> 08:54.740
Now the soft reconfiguration inbound, just a real quick thing on that, it does

171
08:54.740 --> 08:55.480
take more

172
08:55.480 --> 09:01.040
RAM because it is storing a before version of the BGP table.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

172
08:55.480 --> 09:01.040
RAM because it is storing a before version of the BGP table.

173
09:01.040 --> 09:04.790
If you're getting full internet routes from your service provider, that could

174
09:04.790 --> 09:05.320
actually

175
09:05.320 --> 09:07.040
be quite substantial.

176
09:07.040 --> 09:10.970
So just keep in mind the memory usage that it's going to take to do the soft

177
09:10.970 --> 09:12.080
reconfiguration

178
09:12.080 --> 09:13.080
inbound.

179
09:13.080 --> 09:17.440
However, that said, it can also, as I just showed you, be a useful troubles

180
09:17.440 --> 09:19.080
hooting tool.

181
09:19.080 --> 09:22.430
There's other reasons for using it as well, but again, we're not getting that

182
09:22.430 --> 09:22.840
deep into

183
09:22.840 --> 09:25.200
BGP right now.

184
09:25.200 --> 09:28.920
Another important command to make sure that your outbound filters aren't

185
09:28.920 --> 09:29.640
filtering out

186
09:29.640 --> 09:33.490
something they shouldn't, and to see what prefixes you're actually sending to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

186
09:29.640 --> 09:33.490
something they shouldn't, and to see what prefixes you're actually sending to

187
09:33.490 --> 09:35.080
your neighbor,

188
09:35.080 --> 09:38.860
you sort of repeat that last command again, but instead of saying received

189
09:38.860 --> 09:40.000
routes, you

190
09:40.000 --> 09:42.400
say advertised routes.

191
09:42.400 --> 09:45.470
Now this one doesn't really have anything after it unless you want to put in a

192
09:45.470 --> 09:45.880
specific

193
09:45.880 --> 09:50.020
prefix you want to look for, which of course you could just sort of like a

194
09:50.020 --> 09:50.720
filter on the

195
09:50.720 --> 09:51.720
command itself.

196
09:51.720 --> 09:55.790
We'll just say show us everything and we can see that we are in fact

197
09:55.790 --> 09:57.240
advertising our local

198
09:57.240 --> 10:00.280
network out to this neighbor.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

198
09:57.240 --> 10:00.280
network out to this neighbor.

199
10:00.280 --> 10:04.300
The reason we're doing that if we look at our show run section BGP is we see

200
10:04.300 --> 10:05.760
right here,

201
10:05.760 --> 10:11.920
we have a network 10 dot 10 dot 10 dot zero with a mask of a slash 24.

202
10:11.920 --> 10:16.000
That's us advertising that network into BGP.

203
10:16.000 --> 10:20.760
And if we do a show IP interface brief on this router, we do have that address

204
10:20.760 --> 10:21.080
on a

205
10:21.080 --> 10:25.240
locally connected interface that is up up.

206
10:25.240 --> 10:29.320
Therefore, we can advertise it into BGP.

207
10:29.320 --> 10:32.610
So like I said, we're not going to really get into troubleshooting BGP at the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

207
10:29.320 --> 10:32.610
So like I said, we're not going to really get into troubleshooting BGP at the

208
10:32.610 --> 10:33.280
moment.

209
10:33.280 --> 10:35.600
That's going to be coming up in a future skill.

210
10:35.600 --> 10:40.140
However, these are some good commands to watch to make sure that BGP is doing

211
10:40.140 --> 10:42.440
what you want.

212
10:42.440 --> 10:47.190
So in this video, we jumped in and took a look at some useful commands for

213
10:47.190 --> 10:47.960
verifying

214
10:47.960 --> 10:52.310
our underlay network, which of course has to be working for any cloud

215
10:52.310 --> 10:53.520
connectivity.

216
10:53.520 --> 10:58.460
So the key takeaways here, make sure your IP address is set either statically

217
10:58.460 --> 10:59.080
as it should

218
10:59.080 --> 11:01.920
be or set to DHCP.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

218
10:59.080 --> 11:01.920
be or set to DHCP.

219
11:01.920 --> 11:06.000
Of course, make sure that outside interface is up and functional.

220
11:06.000 --> 11:08.800
And then of course, we have to be concerned about our routing.

221
11:08.800 --> 11:11.560
If we're running a static routing environment, then we just want to make sure

222
11:11.560 --> 11:12.400
we have a static

223
11:12.400 --> 11:15.000
default pointing to our service provider.

224
11:15.000 --> 11:19.820
And of course, if we're running BGP, we need to make sure that BGP session is

225
11:19.820 --> 11:21.240
up and working.

226
11:21.240 --> 11:23.560
We need to make sure our neighborhood is functional.

227
11:23.560 --> 11:27.700
There were learning prefixes, particularly probably a default unless you're

228
11:27.700 --> 11:28.360
getting full

229
11:28.360 --> 11:31.600
internet tables, if you're getting the full internet routing table, you don't
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

229
11:28.360 --> 11:31.600
internet tables, if you're getting the full internet routing table, you don't

230
11:31.600 --> 11:32.200
really need

231
11:32.200 --> 11:33.840
a default route.

232
11:33.840 --> 11:38.250
Commonly, it'll be sent as well anyway, but you really don't need one if you're

233
11:38.250 --> 11:38.800
getting

234
11:38.800 --> 11:40.280
full tables.

235
11:40.280 --> 11:42.460
But if you're getting partial tables, you'll want to make sure you're also

236
11:42.460 --> 11:43.400
getting a default

237
11:43.400 --> 11:44.400
route.

238
11:44.400 --> 11:48.700
And of course, the main reason you're probably running BGP to begin with, you

239
11:48.700 --> 11:49.200
want to make

240
11:49.200 --> 11:54.320
sure that your networks that are being advertised out to BGP are being sent to

241
11:54.320 --> 11:55.480
the appropriate

242
11:55.480 --> 11:56.480
neighbors.

243
11:56.480 --> 12:00.200
So now that we have all that functional and we verified that it's working, the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

243
11:56.480 --> 12:00.200
So now that we have all that functional and we verified that it's working, the

244
12:00.200 --> 12:00.720
next step,

245
12:00.720 --> 12:05.780
of course, would be to look at some good commands for verifying our actual IP

246
12:05.780 --> 12:07.360
sec tunnel.

247
12:07.360 --> 12:08.640
That's what we're going to look at next.

248
12:08.640 --> 12:18.640
[BLANK_AUDIO]