1
00:00:00,000 --> 00:00:03,423
[MUSIC PLAYING]

2
00:00:03,423 --> 00:00:07,340

3
00:00:07,340 --> 00:00:10,010
Before we can really
jump in and talk

4
00:00:10,010 --> 00:00:13,700
about manipulating BGP's
attributes in order

5
00:00:13,700 --> 00:00:16,309
to influence our
path selection, we

6
00:00:16,309 --> 00:00:19,490
have to talk about how that
information is going to be

7
00:00:19,490 --> 00:00:21,860
propagated to the neighbors.

8
00:00:21,860 --> 00:00:27,110
BGP does not consider the
changing of attributes

9
00:00:27,110 --> 00:00:30,260
to be an actual
change to the prefix.

10
00:00:30,260 --> 00:00:33,050
If the prefix
itself was changing,

11
00:00:33,050 --> 00:00:35,900
such as maybe the subnet
mask, maybe somebody

12
00:00:35,900 --> 00:00:39,530
summarized it so maybe a
route needs to be withdrawn,

13
00:00:39,530 --> 00:00:43,190
or a new route needs to be
advertised, or something

14
00:00:43,190 --> 00:00:48,050
like the next hop changes,
those are major routing events

15
00:00:48,050 --> 00:00:49,970
and prefix changes.

16
00:00:49,970 --> 00:00:53,870
BGP will, of course, send
those to its neighbors.

17
00:00:53,870 --> 00:00:56,060
If it didn't, it
wouldn't really be

18
00:00:56,060 --> 00:00:59,330
very much of a dynamic
routing protocol.

19
00:00:59,330 --> 00:01:02,300
But the attributes,
the things that we're

20
00:01:02,300 --> 00:01:06,500
trying to use to influence
BGP's path selection,

21
00:01:06,500 --> 00:01:11,160
don't automatically trigger
an update to the neighbors.

22
00:01:11,160 --> 00:01:12,710
This is something
that we're going

23
00:01:12,710 --> 00:01:16,350
to have to do manually
when we make changes.

24
00:01:16,350 --> 00:01:18,630
Now there are a few
ways to do that.

25
00:01:18,630 --> 00:01:22,440
And that's what we're going to
be discussing in this video.

26
00:01:22,440 --> 00:01:25,130
We could, of course,
do a hard reset.

27
00:01:25,130 --> 00:01:27,230
And that's going
to be disruptive.

28
00:01:27,230 --> 00:01:29,990
That's going to take the
neighborship down, bring

29
00:01:29,990 --> 00:01:33,080
the neighborship back
up, and then readvertise

30
00:01:33,080 --> 00:01:35,960
all the prefixes
which, of course, would

31
00:01:35,960 --> 00:01:37,940
include the new attributes.

32
00:01:37,940 --> 00:01:42,020
But that's going to be very
disruptive to network traffic.

33
00:01:42,020 --> 00:01:45,090
And in most environments, we're
not going to want to do that.

34
00:01:45,090 --> 00:01:48,050
So we have two other
choices which is

35
00:01:48,050 --> 00:01:50,190
the main topic of this video.

36
00:01:50,190 --> 00:01:53,060
We're going to be talking
about soft reconfiguration

37
00:01:53,060 --> 00:01:56,030
and something called
route refresh.

38
00:01:56,030 --> 00:01:59,090
Now route refresh is
generally considered newer

39
00:01:59,090 --> 00:02:02,100
and that's generally
what we use.

40
00:02:02,100 --> 00:02:06,530
However, soft reconfiguration
does have one advantage

41
00:02:06,530 --> 00:02:09,470
that you might want to consider
to help us maybe a little bit

42
00:02:09,470 --> 00:02:11,009
with some troubleshooting.

43
00:02:11,009 --> 00:02:12,590
So let's jump in
and get started.

44
00:02:12,590 --> 00:02:15,410
And we'll take a look
at the attributes

45
00:02:15,410 --> 00:02:18,620
of each different method.

46
00:02:18,620 --> 00:02:20,530
So the first option
we'll discuss

47
00:02:20,530 --> 00:02:23,410
is soft reconfiguration.

48
00:02:23,410 --> 00:02:26,390
And as we said during
the introduction,

49
00:02:26,390 --> 00:02:29,200
this is sort of
considered the older way

50
00:02:29,200 --> 00:02:31,010
of accomplishing this.

51
00:02:31,010 --> 00:02:34,630
So let's jump in and talk
about its attributes.

52
00:02:34,630 --> 00:02:38,980
First, it stores a
copy of the routes that

53
00:02:38,980 --> 00:02:44,350
were received from a neighbor
before running those routes

54
00:02:44,350 --> 00:02:47,660
through the inbound policies.

55
00:02:47,660 --> 00:02:51,670
So the idea here is we
can take this stored copy

56
00:02:51,670 --> 00:02:55,750
and run it back through
our inbound filters again

57
00:02:55,750 --> 00:02:58,510
if those inbound filters change.

58
00:02:58,510 --> 00:03:00,770
The big advantage
to this, of course,

59
00:03:00,770 --> 00:03:04,690
is we don't have to do a hard
reset on the neighborship.

60
00:03:04,690 --> 00:03:08,790
We simply replay the
locally stored copy.

61
00:03:08,790 --> 00:03:12,220
Now this feature is
not enabled by default

62
00:03:12,220 --> 00:03:17,500
so it does have to be manually
enabled in order to use it.

63
00:03:17,500 --> 00:03:19,060
And the reason for
this we'll see you

64
00:03:19,060 --> 00:03:21,000
in the next couple
of points here.

65
00:03:21,000 --> 00:03:25,230
Something else to
note that on iOS XR,

66
00:03:25,230 --> 00:03:28,770
this actually will
not work by default

67
00:03:28,770 --> 00:03:32,850
if the neighbor supports
the newer route refresh.

68
00:03:32,850 --> 00:03:35,130
Even if you enable
this feature, it

69
00:03:35,130 --> 00:03:39,870
will still do a route refresh
if the neighbor supports it

70
00:03:39,870 --> 00:03:41,490
since that is
generally considered

71
00:03:41,490 --> 00:03:42,790
to be the newer method.

72
00:03:42,790 --> 00:03:46,270
And we'll see this when we
get to our demonstration.

73
00:03:46,270 --> 00:03:48,840
Now I think that the
main reason we still

74
00:03:48,840 --> 00:03:51,420
want to discuss
soft reconfiguration

75
00:03:51,420 --> 00:03:53,880
is because of this
point right here.

76
00:03:53,880 --> 00:03:57,390
This can be very
useful, specifically

77
00:03:57,390 --> 00:03:59,430
for troubleshooting.

78
00:03:59,430 --> 00:04:01,170
And what we mean by this--

79
00:04:01,170 --> 00:04:04,380
troubleshooting your
inbound filters.

80
00:04:04,380 --> 00:04:07,630
If your inbound
filters are not correct

81
00:04:07,630 --> 00:04:10,080
and you are filtering out
things you don't want to,

82
00:04:10,080 --> 00:04:13,470
or maybe you're not filtering
out the things you do want to,

83
00:04:13,470 --> 00:04:16,260
in any case, it
can be incredibly

84
00:04:16,260 --> 00:04:19,837
useful to see the before
copy of the routes

85
00:04:19,837 --> 00:04:21,420
that you're getting
from your neighbor

86
00:04:21,420 --> 00:04:26,010
compared to what you're putting
into your routing table or BGP

87
00:04:26,010 --> 00:04:27,130
table.

88
00:04:27,130 --> 00:04:29,730
So the way this is
useful is allowing

89
00:04:29,730 --> 00:04:34,440
you to see that before and after
snapshot of the prefixes being

90
00:04:34,440 --> 00:04:36,690
learned from a neighbor
and therefore get

91
00:04:36,690 --> 00:04:40,380
a really good idea of what
your inbound filters are doing.

92
00:04:40,380 --> 00:04:43,470
Now given all this information
about how this works,

93
00:04:43,470 --> 00:04:46,800
hopefully, it's no
big surprise that this

94
00:04:46,800 --> 00:04:51,630
is going to take additional
RAM on that router.

95
00:04:51,630 --> 00:04:56,140
The before and after BGP tables
do have to be stored somewhere.

96
00:04:56,140 --> 00:04:58,530
Now the after
table, of course, we

97
00:04:58,530 --> 00:05:01,050
will always have so
that's not additional.

98
00:05:01,050 --> 00:05:05,790
But storing that before copy of
the BGP table from the neighbor

99
00:05:05,790 --> 00:05:08,340
is definitely going
to take more RAM.

100
00:05:08,340 --> 00:05:10,140
On today's equipment,
that probably

101
00:05:10,140 --> 00:05:13,080
doesn't matter a whole
lot but we do still

102
00:05:13,080 --> 00:05:15,630
need to take it into
consideration when

103
00:05:15,630 --> 00:05:19,140
we're going to consider
enabling this feature.

104
00:05:19,140 --> 00:05:23,300
Now the second option
here is route refresh.

105
00:05:23,300 --> 00:05:26,030
And as I mentioned,
this is generally

106
00:05:26,030 --> 00:05:28,010
considered to be
the newer option.

107
00:05:28,010 --> 00:05:33,950
This entails actually
requesting the full BGP table

108
00:05:33,950 --> 00:05:35,900
to be resent.

109
00:05:35,900 --> 00:05:37,290
That's the key here.

110
00:05:37,290 --> 00:05:41,310
We're not storing the
unaltered copy anymore.

111
00:05:41,310 --> 00:05:43,790
If we change our
inbound filters,

112
00:05:43,790 --> 00:05:47,840
we simply ask our neighbor
to send all the updates again

113
00:05:47,840 --> 00:05:50,210
and then we run them
through our new filters.

114
00:05:50,210 --> 00:05:52,850
So rather than us
storing a copy,

115
00:05:52,850 --> 00:05:56,000
this gives us a mechanism
to simply request

116
00:05:56,000 --> 00:06:00,530
the neighbor to send us
another copy on its own.

117
00:06:00,530 --> 00:06:04,520
The reason for doing this
is to take those new updates

118
00:06:04,520 --> 00:06:07,580
and pass them
through the changes

119
00:06:07,580 --> 00:06:10,490
to our new inbound policies.

120
00:06:10,490 --> 00:06:13,460
But we don't store a local copy.

121
00:06:13,460 --> 00:06:17,330
Now this capability is going
to have to be negotiated

122
00:06:17,330 --> 00:06:19,550
when the neighborship comes up.

123
00:06:19,550 --> 00:06:23,480
I cannot send you a route
refresh message if you

124
00:06:23,480 --> 00:06:26,100
don't understand route
refresh messages.

125
00:06:26,100 --> 00:06:29,670
So I have to know that
you know what they are.

126
00:06:29,670 --> 00:06:32,700
This feature was not in
BGP from the beginning.

127
00:06:32,700 --> 00:06:35,210
So therefore, there
is a possibility

128
00:06:35,210 --> 00:06:38,720
that a BGP router
on the other end

129
00:06:38,720 --> 00:06:41,010
would not understand
this feature.

130
00:06:41,010 --> 00:06:43,280
Now this is another
one of those features

131
00:06:43,280 --> 00:06:45,950
that every vendor
out there that I'm

132
00:06:45,950 --> 00:06:50,150
aware of supports route refresh
but it doesn't mean they

133
00:06:50,150 --> 00:06:51,240
have to.

134
00:06:51,240 --> 00:06:55,010
So we do have to negotiate
this so that both routers are

135
00:06:55,010 --> 00:06:58,610
on the same page and they know
whether their neighbor supports

136
00:06:58,610 --> 00:07:02,030
this before we just go
asking for a route refresh

137
00:07:02,030 --> 00:07:06,350
and the other router has no
idea what we're talking about.

138
00:07:06,350 --> 00:07:10,630
So those route refresh messages
that we just mentioned come

139
00:07:10,630 --> 00:07:12,790
in a few different flavors.

140
00:07:12,790 --> 00:07:16,400
First, we have the
refresh request.

141
00:07:16,400 --> 00:07:19,660
Then we have a start of
rib message telling us

142
00:07:19,660 --> 00:07:22,660
that it's about to
send the rib to us.

143
00:07:22,660 --> 00:07:29,270
Then we have an adjacency rib
out and an end of rib message.

144
00:07:29,270 --> 00:07:31,370
Now we don't really have
to be familiar with these

145
00:07:31,370 --> 00:07:32,730
in great detail.

146
00:07:32,730 --> 00:07:35,180
However I would be aware
of the different message

147
00:07:35,180 --> 00:07:37,610
types used by route refresh.

148
00:07:37,610 --> 00:07:40,850
And here's arguably the best
feature of this whole thing

149
00:07:40,850 --> 00:07:47,660
is most modern code, most
new versions of iOS, both XR

150
00:07:47,660 --> 00:07:51,860
and XE, have this feature
enabled by default.

151
00:07:51,860 --> 00:07:55,670
And in fact, most of
them will prefer this

152
00:07:55,670 --> 00:07:58,910
even if you enable
soft reconfiguration.

153
00:07:58,910 --> 00:08:02,030
We might have to force
soft reconfiguration

154
00:08:02,030 --> 00:08:07,010
to happen over route refresh,
particularly on iOS XR,

155
00:08:07,010 --> 00:08:10,020
but we'll see that
in our demonstration.

156
00:08:10,020 --> 00:08:13,880
And one final point here that
since this is not taking up

157
00:08:13,880 --> 00:08:17,390
extra RAM, what
we're doing instead

158
00:08:17,390 --> 00:08:20,810
is we're going to be asking
our neighbor to resend this.

159
00:08:20,810 --> 00:08:23,240
That's exactly what
we mentioned up here.

160
00:08:23,240 --> 00:08:26,790
The whole concept of
resending is, of course,

161
00:08:26,790 --> 00:08:28,910
going to take
bandwidth on the link

162
00:08:28,910 --> 00:08:32,940
and therefore
slightly more time.

163
00:08:32,940 --> 00:08:35,840
Now, I wouldn't
consider the extra time

164
00:08:35,840 --> 00:08:39,289
to really be an issue on
most of today's networks

165
00:08:39,289 --> 00:08:41,280
with our available bandwidth.

166
00:08:41,280 --> 00:08:43,940
However, we can't
really argue the fact

167
00:08:43,940 --> 00:08:46,100
that getting the
neighbor to resend it

168
00:08:46,100 --> 00:08:50,510
is still going to take even
marginally more time than just

169
00:08:50,510 --> 00:08:55,570
replaying a local copy
out of our own local RAM.

170
00:08:55,570 --> 00:08:57,940
In our next video,
we're going to be

171
00:08:57,940 --> 00:09:01,120
taking a look at the
command line and Wireshark

172
00:09:01,120 --> 00:09:05,720
to get a better idea on how
these two features work.

173
00:09:05,720 --> 00:09:09,530
So let's jump in and take
a look at the topology

174
00:09:09,530 --> 00:09:12,790
so we have an idea what we'll
be looking at when we start

175
00:09:12,790 --> 00:09:15,080
jumping into the command line.

176
00:09:15,080 --> 00:09:19,510
So for this skill, we will
be using BGP topology I.

177
00:09:19,510 --> 00:09:22,240
And our topology
doesn't really matter

178
00:09:22,240 --> 00:09:24,440
for this particular
demonstration.

179
00:09:24,440 --> 00:09:28,040
Of course, it will be much more
important in the other videos.

180
00:09:28,040 --> 00:09:30,400
But in this one just looking
at the route refresh,

181
00:09:30,400 --> 00:09:35,170
we're just going to focus
on router 1 and router 7.

182
00:09:35,170 --> 00:09:42,040
This way we can see how both
iOS XR and iOS XE operate.

183
00:09:42,040 --> 00:09:45,420
So in this video, we
took a look at two

184
00:09:45,420 --> 00:09:48,480
features we have
available in BGP

185
00:09:48,480 --> 00:09:52,410
that allow us to send
prefixes with modified

186
00:09:52,410 --> 00:09:56,130
attributes to our
neighbors without actually

187
00:09:56,130 --> 00:09:58,480
having to do a hard reset.

188
00:09:58,480 --> 00:10:01,770
So we started off by
looking at the older method,

189
00:10:01,770 --> 00:10:04,920
doing soft reconfiguration
inbound, where

190
00:10:04,920 --> 00:10:09,510
we keep a local copy of
the unmodified BGP table

191
00:10:09,510 --> 00:10:12,690
before we run it through
our inbound filters.

192
00:10:12,690 --> 00:10:15,600
Then, we took a look
at the more modern way

193
00:10:15,600 --> 00:10:19,110
of doing this, route
refresh, where we actually

194
00:10:19,110 --> 00:10:23,700
send a message to our neighbor
router asking them to resend

195
00:10:23,700 --> 00:10:26,250
the updates to us so
that we can run them

196
00:10:26,250 --> 00:10:29,670
through our new
modified filters.

197
00:10:29,670 --> 00:10:31,830
I hope this has been
informative for you.

198
00:10:31,830 --> 00:10:34,940
And I'd like to thank
you for viewing.

199
00:10:34,940 --> 00:10:38,000