1
00:00:00,000 --> 00:00:03,360
[AUDIO LOGO]

2
00:00:03,360 --> 00:00:08,160

3
00:00:08,160 --> 00:00:11,040
So now let's jump in
and look at some methods

4
00:00:11,040 --> 00:00:15,810
we can use to increase
BGP's performance as far

5
00:00:15,810 --> 00:00:18,550
as decreasing the
convergence time.

6
00:00:18,550 --> 00:00:21,330
But keep in mind
as we jump in here,

7
00:00:21,330 --> 00:00:25,840
BGP is designed to
be slow on purpose.

8
00:00:25,840 --> 00:00:29,280
This is because it's designed
to carry a large quantity

9
00:00:29,280 --> 00:00:31,680
of routes into the millions.

10
00:00:31,680 --> 00:00:34,680
And in doing so, that
does mean that we

11
00:00:34,680 --> 00:00:37,860
have to sacrifice a
little bit of performance

12
00:00:37,860 --> 00:00:42,640
to get stability, the main
focus being on stability.

13
00:00:42,640 --> 00:00:45,660
So as we talk about
increasing performance,

14
00:00:45,660 --> 00:00:48,450
we do have to have a
very careful balance

15
00:00:48,450 --> 00:00:50,520
to make sure that
we're not going

16
00:00:50,520 --> 00:00:53,100
to overwhelm our equipment
while we're trying

17
00:00:53,100 --> 00:00:55,690
to increase BGP's performance.

18
00:00:55,690 --> 00:00:57,420
So one of the things
that we're going

19
00:00:57,420 --> 00:00:59,850
to be looking at
in this video is

20
00:00:59,850 --> 00:01:03,510
how to monitor that
performance as we increase

21
00:01:03,510 --> 00:01:07,980
BGP's performance to make sure
that we have that good balance

22
00:01:07,980 --> 00:01:10,380
and that we're not
overwhelming BGP.

23
00:01:10,380 --> 00:01:11,940
So let's go ahead
and jump in and get

24
00:01:11,940 --> 00:01:13,845
started looking at
some of these details.

25
00:01:13,845 --> 00:01:16,460

26
00:01:16,460 --> 00:01:19,300
So again, keep in mind
as we jump in here

27
00:01:19,300 --> 00:01:22,990
that BGP convergence
specifically improving

28
00:01:22,990 --> 00:01:27,340
its performance is
a balance, again,

29
00:01:27,340 --> 00:01:31,720
between making it faster
and not overwhelming

30
00:01:31,720 --> 00:01:36,130
the routers, in other words,
stability versus performance.

31
00:01:36,130 --> 00:01:38,380
We have to keep
this in mind when

32
00:01:38,380 --> 00:01:42,190
we're talking about tweaking
and modifying BGP's timers.

33
00:01:42,190 --> 00:01:46,720
So what is converged
from a BGP perspective?

34
00:01:46,720 --> 00:01:51,610
Well, first it means that all
the routes have been received.

35
00:01:51,610 --> 00:01:55,330
It also means that the
appropriate routes,

36
00:01:55,330 --> 00:01:57,700
and of course, by this,
we mean the routes that

37
00:01:57,700 --> 00:02:01,270
have been selected as best
have a valid next hop,

38
00:02:01,270 --> 00:02:04,390
pass the synchronization
rule if that's enabled.

39
00:02:04,390 --> 00:02:08,979
But as long as they're the
best or the appropriate routes,

40
00:02:08,979 --> 00:02:13,570
they are then placed into the
routing and forwarding tables

41
00:02:13,570 --> 00:02:18,340
meaning, of course, the RIB
and the FIB on the device.

42
00:02:18,340 --> 00:02:25,630
And also that the input and
output queues are empty.

43
00:02:25,630 --> 00:02:28,020
If these queues
are not empty, it

44
00:02:28,020 --> 00:02:30,570
means that you're either
waiting to send information

45
00:02:30,570 --> 00:02:35,430
to a neighbor or you're still
processing updates that you've

46
00:02:35,430 --> 00:02:37,440
received from a neighbor.

47
00:02:37,440 --> 00:02:39,930
Either way, this
indicates that you

48
00:02:39,930 --> 00:02:42,960
have a problem sending
and receiving updates

49
00:02:42,960 --> 00:02:44,230
to your neighbors.

50
00:02:44,230 --> 00:02:47,220
Now, keep in mind when
you're looking at this,

51
00:02:47,220 --> 00:02:50,550
if you just do one show command
and you see some packets

52
00:02:50,550 --> 00:02:54,090
or updates in the input
and output queues, that's

53
00:02:54,090 --> 00:02:55,680
nothing to panic about.

54
00:02:55,680 --> 00:02:57,990
It can happen on
occasion depending

55
00:02:57,990 --> 00:03:00,870
on exactly which
millisecond you happen

56
00:03:00,870 --> 00:03:03,150
to look at that show command.

57
00:03:03,150 --> 00:03:05,160
Repeat the command a few times.

58
00:03:05,160 --> 00:03:10,000
Just make sure that it's
not staying that way.

59
00:03:10,000 --> 00:03:12,330
Now, there are a
few major components

60
00:03:12,330 --> 00:03:15,270
that affect BGP convergence.

61
00:03:15,270 --> 00:03:19,840
The first of these are
the BGP keepalives.

62
00:03:19,840 --> 00:03:21,190
Why is this important?

63
00:03:21,190 --> 00:03:24,690
Well, this is how we detect
a failure, how we detect

64
00:03:24,690 --> 00:03:26,800
if a neighborship goes down.

65
00:03:26,800 --> 00:03:31,680
So by default, these are
only sent every 60 seconds.

66
00:03:31,680 --> 00:03:33,700
And the issue with
that, of course,

67
00:03:33,700 --> 00:03:36,540
is we have to miss
three in order

68
00:03:36,540 --> 00:03:38,670
to declare a neighbor down.

69
00:03:38,670 --> 00:03:42,990
That means it's going to be 180
seconds to detect a neighbor's

70
00:03:42,990 --> 00:03:44,980
failure.

71
00:03:44,980 --> 00:03:49,410
Now oftentimes, this is OK
because this can actually

72
00:03:49,410 --> 00:03:50,880
help BGP.

73
00:03:50,880 --> 00:03:55,080
If there is a failure on
the underlying network,

74
00:03:55,080 --> 00:04:00,510
our IGP may converge fast
enough that BGP never even

75
00:04:00,510 --> 00:04:02,820
knows the neighbors down.

76
00:04:02,820 --> 00:04:04,750
That's the plus side.

77
00:04:04,750 --> 00:04:08,340
The negative side is if
the neighbor is down,

78
00:04:08,340 --> 00:04:10,600
and there is no other
path to get there,

79
00:04:10,600 --> 00:04:14,410
it's going to take three minutes
until BGP figures this out.

80
00:04:14,410 --> 00:04:16,890
So again, we don't
necessarily want

81
00:04:16,890 --> 00:04:19,890
to go incredibly
aggressive here,

82
00:04:19,890 --> 00:04:21,450
but we do probably
want to speed it

83
00:04:21,450 --> 00:04:24,840
up a little bit in
most environments.

84
00:04:24,840 --> 00:04:26,900
Now this can, of
course, be supplemented

85
00:04:26,900 --> 00:04:30,710
by BFD or bidirectional
forwarding detection,

86
00:04:30,710 --> 00:04:33,770
and we can detect
failures much quicker.

87
00:04:33,770 --> 00:04:38,220
The second component
is the BGP scanner.

88
00:04:38,220 --> 00:04:41,700
The job of the BGP
scanner is it looks

89
00:04:41,700 --> 00:04:44,820
at the unicast routing
table or the RIB

90
00:04:44,820 --> 00:04:47,880
to verify next hop reachability.

91
00:04:47,880 --> 00:04:50,140
If the next hop is not
reachable, of course,

92
00:04:50,140 --> 00:04:53,530
we can't install the route
into the routing table.

93
00:04:53,530 --> 00:04:57,790
Now by default, this
runs every 60 seconds.

94
00:04:57,790 --> 00:05:01,560
That means that when I
receive an update, depending

95
00:05:01,560 --> 00:05:04,530
on exactly the last time
the BGP scanner ran,

96
00:05:04,530 --> 00:05:10,860
it could take up to 59.9 seconds
before that route can actually

97
00:05:10,860 --> 00:05:12,630
be installed into
the routing table

98
00:05:12,630 --> 00:05:15,960
because we have to
verify that next hop.

99
00:05:15,960 --> 00:05:18,570
Now the big concern
with speeding this up

100
00:05:18,570 --> 00:05:22,650
is it can take a lot
of CPU, particularly

101
00:05:22,650 --> 00:05:25,570
if we have a large BGP table.

102
00:05:25,570 --> 00:05:27,900
So once again, do
we probably want

103
00:05:27,900 --> 00:05:31,560
to speed it up from 60 seconds
on most of today's platforms?

104
00:05:31,560 --> 00:05:32,850
Yeah probably.

105
00:05:32,850 --> 00:05:35,310
But once again, we
have to be careful.

106
00:05:35,310 --> 00:05:36,960
And we'll see in
just a moment how

107
00:05:36,960 --> 00:05:39,510
to watch our components to
make sure that we're not

108
00:05:39,510 --> 00:05:41,760
overwhelming the router.

109
00:05:41,760 --> 00:05:47,070
Our final component is
the BGP update pacing.

110
00:05:47,070 --> 00:05:50,400
By default, we limit
sending updates

111
00:05:50,400 --> 00:05:55,960
to eBGP peers to
only 30 seconds.

112
00:05:55,960 --> 00:06:00,870
Now, this does not limit
updates going to iBGP.

113
00:06:00,870 --> 00:06:03,390
So this is just
for external peers.

114
00:06:03,390 --> 00:06:06,900
And we've mentioned this
a few times previously.

115
00:06:06,900 --> 00:06:11,400
But BGP will by default
only send updates

116
00:06:11,400 --> 00:06:15,490
after 30 seconds to eBGP peers.

117
00:06:15,490 --> 00:06:19,290
So that's just something else
that we want to be aware of.

118
00:06:19,290 --> 00:06:22,130
Now as we've mentioned,
one of the biggest things

119
00:06:22,130 --> 00:06:25,610
we need to be concerned about
before we start modifying

120
00:06:25,610 --> 00:06:28,340
and updating these timers
and these settings is we

121
00:06:28,340 --> 00:06:30,350
need to make sure
we're keeping track

122
00:06:30,350 --> 00:06:32,390
of the performance
of our routers,

123
00:06:32,390 --> 00:06:34,700
making sure they're not
getting overwhelmed.

124
00:06:34,700 --> 00:06:37,550
So before we jump into
things we can and should

125
00:06:37,550 --> 00:06:42,020
change or possibly modify, let's
take a look at the command line

126
00:06:42,020 --> 00:06:43,880
and take a look at some
of the good commands

127
00:06:43,880 --> 00:06:46,960
that we want to keep an eye on.

128
00:06:46,960 --> 00:06:49,320
So let's start on iOS XE.

129
00:06:49,320 --> 00:06:51,370
We'll just use router 7 here.

130
00:06:51,370 --> 00:06:53,700
And one of the first
things you want to watch

131
00:06:53,700 --> 00:06:57,120
is a show proc CPU.

132
00:06:57,120 --> 00:06:59,760
And a good filter I
like to use with this

133
00:06:59,760 --> 00:07:07,220
is to say, include BGP or
from the beginning of the line

134
00:07:07,220 --> 00:07:09,980
PID, which is your process ID.

135
00:07:09,980 --> 00:07:12,440
The reason I'm using
this regular expression

136
00:07:12,440 --> 00:07:15,590
is when we look at it,
it's nice because we

137
00:07:15,590 --> 00:07:19,040
get the header up at
the top to tell us what

138
00:07:19,040 --> 00:07:21,030
each of these columns means.

139
00:07:21,030 --> 00:07:23,540
So of course, the big
things we want to watch here

140
00:07:23,540 --> 00:07:29,730
is for any process in BGP
running away with our CPU.

141
00:07:29,730 --> 00:07:31,820
Now we can, of course,
see here in our lab,

142
00:07:31,820 --> 00:07:34,610
it's taking 0% of our CPU.

143
00:07:34,610 --> 00:07:37,730
But we would not see it this
way in a large production

144
00:07:37,730 --> 00:07:39,030
environment.

145
00:07:39,030 --> 00:07:44,390
Another command that I like to
use is show proc CPU history.

146
00:07:44,390 --> 00:07:47,480
This actually gives
us an ASCII chart

147
00:07:47,480 --> 00:07:50,700
to show us over the
last 60 seconds.

148
00:07:50,700 --> 00:07:55,250
And if we scroll down,
it'll show us 60 minutes.

149
00:07:55,250 --> 00:08:00,530
And if we scroll down further,
it shows us the last 72 hours.

150
00:08:00,530 --> 00:08:03,110
Since this is the only one
that's really populated,

151
00:08:03,110 --> 00:08:04,970
we can see that
this is giving us

152
00:08:04,970 --> 00:08:08,450
a history of where the CPU
has been on this device

153
00:08:08,450 --> 00:08:10,760
over the last three days.

154
00:08:10,760 --> 00:08:12,440
As far as memory,
we can actually

155
00:08:12,440 --> 00:08:14,390
repeat this last command
here, but instead

156
00:08:14,390 --> 00:08:19,560
of saying show proc CPU, we
can say show proc memory.

157
00:08:19,560 --> 00:08:21,800
This is going to show us
the same basic information.

158
00:08:21,800 --> 00:08:24,560
Once again, we get
the headers, and we

159
00:08:24,560 --> 00:08:27,440
can see if memory
is being consumed

160
00:08:27,440 --> 00:08:30,440
by any of our BGP processes.

161
00:08:30,440 --> 00:08:33,710
Of course, if we do a show
proc memory without the filter,

162
00:08:33,710 --> 00:08:38,059
we can also find out at the top
the total amount that's used

163
00:08:38,059 --> 00:08:41,490
and how much is free because we
would also want to make sure,

164
00:08:41,490 --> 00:08:44,059
of course, that we're not
running out of free memory

165
00:08:44,059 --> 00:08:45,790
either.

166
00:08:45,790 --> 00:08:49,530
And the last major thing we want
to watch if we do a show IP BGP

167
00:08:49,530 --> 00:08:53,680
summary, we want to watch
these input and output

168
00:08:53,680 --> 00:08:56,470
queues going to our neighbors.

169
00:08:56,470 --> 00:08:59,240
Again, if you happen
to do this show command

170
00:08:59,240 --> 00:09:01,270
and you see a couple
of things in the queue,

171
00:09:01,270 --> 00:09:03,100
it's not really a big deal.

172
00:09:03,100 --> 00:09:04,600
Just repeat the command.

173
00:09:04,600 --> 00:09:07,090
We just want to make sure that
there's not things sitting

174
00:09:07,090 --> 00:09:09,550
in those queues regularly.

175
00:09:09,550 --> 00:09:13,730
Again, once in a while, if you
happen to cat it, that's fine.

176
00:09:13,730 --> 00:09:16,690
So those are good things
to watch on iOS XE.

177
00:09:16,690 --> 00:09:19,510
Let's jump over to iOS XR.

178
00:09:19,510 --> 00:09:21,520
We'll just use router 1.

179
00:09:21,520 --> 00:09:24,583
So here we can do
a show proc CPU.

180
00:09:24,583 --> 00:09:26,750
The filtering here is a
little bit different though.

181
00:09:26,750 --> 00:09:28,660
We're just going
to say include bgp.

182
00:09:28,660 --> 00:09:30,640
It's lowercase.

183
00:09:30,640 --> 00:09:33,250
And here we can see
our BGP processes

184
00:09:33,250 --> 00:09:35,350
and what they're
currently using.

185
00:09:35,350 --> 00:09:40,720
Now unfortunately on iOS XR,
if we just do a show proc CPU,

186
00:09:40,720 --> 00:09:44,200
we can see here that the top
looks about the same as far

187
00:09:44,200 --> 00:09:46,480
as the headers like the PID.

188
00:09:46,480 --> 00:09:48,880
However, if we were to
go back to our filter

189
00:09:48,880 --> 00:09:55,210
and say BGP or PID,
iOS XR doesn't actually

190
00:09:55,210 --> 00:09:59,440
like using the or regular
expression in the output

191
00:09:59,440 --> 00:10:00,680
of the show command.

192
00:10:00,680 --> 00:10:02,860
So unfortunately,
we would just have

193
00:10:02,860 --> 00:10:04,600
to do it with and
without the filter

194
00:10:04,600 --> 00:10:07,510
and happen to know
what the headers are.

195
00:10:07,510 --> 00:10:11,320
Another good one to watch
here is the show proc blocked.

196
00:10:11,320 --> 00:10:13,210
This will show us
any applications

197
00:10:13,210 --> 00:10:17,080
that have actually been
blocked from using the CPU.

198
00:10:17,080 --> 00:10:20,920
We would not want to
see BGP on this list.

199
00:10:20,920 --> 00:10:26,140
Another good one, show
watchdog memory state.

200
00:10:26,140 --> 00:10:29,810
We can see here that our
current memory state is normal.

201
00:10:29,810 --> 00:10:32,680
So again, we would want to make
sure that our free memory is

202
00:10:32,680 --> 00:10:34,630
not getting too low.

203
00:10:34,630 --> 00:10:37,720
We could do a show
memory compare start.

204
00:10:37,720 --> 00:10:39,250
We see what it's
doing is actually

205
00:10:39,250 --> 00:10:42,110
storing a memory snapshot.

206
00:10:42,110 --> 00:10:45,190
So this would be like the
beginning of our baselining.

207
00:10:45,190 --> 00:10:49,610
Then when we were done, you
would think it would be stop--

208
00:10:49,610 --> 00:10:51,200
start and stop.

209
00:10:51,200 --> 00:10:52,480
No, its end.

210
00:10:52,480 --> 00:10:53,650
That's OK.

211
00:10:53,650 --> 00:10:56,090
But this makes the end.

212
00:10:56,090 --> 00:10:58,820
And then you can
ask for the report.

213
00:10:58,820 --> 00:11:01,940
Now the report is going
to be fairly long.

214
00:11:01,940 --> 00:11:04,620
As we can see, it's going
to go on for a bit here.

215
00:11:04,620 --> 00:11:08,360
So what we might want to do
is, again filter that output

216
00:11:08,360 --> 00:11:11,280
and just say to include BGP.

217
00:11:11,280 --> 00:11:13,070
So we can see that
this way it only

218
00:11:13,070 --> 00:11:16,690
returns the BGP information.

219
00:11:16,690 --> 00:11:20,320
In this video, we took a
look at some of the things

220
00:11:20,320 --> 00:11:24,910
that we might want to change
in relation to BGP convergence

221
00:11:24,910 --> 00:11:28,850
and speeding it up a little bit
to make it a little bit faster.

222
00:11:28,850 --> 00:11:31,480
We also took a look
at the command line

223
00:11:31,480 --> 00:11:34,450
to see things that we need
to watch for on the router

224
00:11:34,450 --> 00:11:36,890
before we start
making those changes,

225
00:11:36,890 --> 00:11:40,600
and after we make those changes,
to make sure that we're not

226
00:11:40,600 --> 00:11:42,670
overwhelming the router.

227
00:11:42,670 --> 00:11:44,890
I hope this has been
informative for you.

228
00:11:44,890 --> 00:11:47,970
And I'd like to thank
you for viewing.

229
00:11:47,970 --> 00:11:51,000