1
00:00:00,000 --> 00:00:02,868
[AUDIO LOGO]

2
00:00:02,868 --> 00:00:07,180

3
00:00:07,180 --> 00:00:09,790
So now that we've seen
how weight operates,

4
00:00:09,790 --> 00:00:12,620
let's take a look
at local preference.

5
00:00:12,620 --> 00:00:15,580
Now, we're going to see as
we go through this video

6
00:00:15,580 --> 00:00:19,570
that local preference in a way
is quite similar to weight.

7
00:00:19,570 --> 00:00:23,650
We're going to use it to affect
our outbound routing decisions.

8
00:00:23,650 --> 00:00:26,110
Now, of course, where
it's very different

9
00:00:26,110 --> 00:00:30,250
is that this is a BGP
attribute and therefore

10
00:00:30,250 --> 00:00:33,350
gets passed in BGP updates.

11
00:00:33,350 --> 00:00:36,490
So let's jump in and take a
look at some of its details.

12
00:00:36,490 --> 00:00:39,410
And then of course, we'll
bring up a diagram at the end

13
00:00:39,410 --> 00:00:43,360
and get an idea of how we can
use this to influence our BGP

14
00:00:43,360 --> 00:00:46,190
path selection.

15
00:00:46,190 --> 00:00:50,780
Local preference is actually
referenced in BGP rule number

16
00:00:50,780 --> 00:00:55,580
two, where we're going to
prefer the path with the highest

17
00:00:55,580 --> 00:00:57,240
local preference.

18
00:00:57,240 --> 00:01:02,030
So once again, this is a value
where the highest wins, just

19
00:01:02,030 --> 00:01:03,770
like weight.

20
00:01:03,770 --> 00:01:06,260
And just like
weight, this is also

21
00:01:06,260 --> 00:01:12,300
used to set the preferred
outbound eBGP path.

22
00:01:12,300 --> 00:01:15,560
Now, just like we mentioned
briefly in our discussion

23
00:01:15,560 --> 00:01:19,520
during weight, this can
also be used in conjunction

24
00:01:19,520 --> 00:01:22,550
with communities
and possibly used

25
00:01:22,550 --> 00:01:25,010
to influence the return path.

26
00:01:25,010 --> 00:01:27,080
But generally
speaking, again, this

27
00:01:27,080 --> 00:01:30,990
is going to be for
outbound path selection.

28
00:01:30,990 --> 00:01:34,350
And one of the primary
reasons that it's for outbound

29
00:01:34,350 --> 00:01:40,440
is that this is only going to be
propagated within the AS, which

30
00:01:40,440 --> 00:01:45,540
means it's only going to be sent
to iBGP peers and confederation

31
00:01:45,540 --> 00:01:50,440
peers since those would be
part of the same AS as well.

32
00:01:50,440 --> 00:01:52,560
Now, some of the
advantages of using

33
00:01:52,560 --> 00:01:55,000
local preference over weight--

34
00:01:55,000 --> 00:01:57,220
well, the first here
is this of course

35
00:01:57,220 --> 00:02:01,830
allows for a consistent
domain routing policy.

36
00:02:01,830 --> 00:02:05,850
The reason is that this value is
passed through the BGP updates

37
00:02:05,850 --> 00:02:07,930
within the domain.

38
00:02:07,930 --> 00:02:11,790
Now, we don't generally want to
use weight and local preference

39
00:02:11,790 --> 00:02:13,140
together.

40
00:02:13,140 --> 00:02:16,240
Normally, we're going
to choose one to use.

41
00:02:16,240 --> 00:02:18,900
So we really want to
avoid using weight here.

42
00:02:18,900 --> 00:02:22,800
But again, keep in mind that if
you do have one router that you

43
00:02:22,800 --> 00:02:24,510
needed to make a
different decision,

44
00:02:24,510 --> 00:02:27,690
weight can still override
local preference.

45
00:02:27,690 --> 00:02:29,790
It's just generally
not recommended

46
00:02:29,790 --> 00:02:33,000
unless you have a very
specific reason to do so.

47
00:02:33,000 --> 00:02:35,190
For the same reason,
we sort of want

48
00:02:35,190 --> 00:02:41,110
to avoid changing the local
preference inside the domain.

49
00:02:41,110 --> 00:02:42,840
Now, the main
reason for this one

50
00:02:42,840 --> 00:02:45,480
is to get that
consistent routing policy

51
00:02:45,480 --> 00:02:47,080
we were just talking about.

52
00:02:47,080 --> 00:02:49,890
It's not going to be
consistent if we change

53
00:02:49,890 --> 00:02:52,180
things inside the domain.

54
00:02:52,180 --> 00:02:55,320
Now, the implication here, in
case you didn't pick up on it,

55
00:02:55,320 --> 00:02:59,440
is that means that when we get
updates from our neighbors--

56
00:02:59,440 --> 00:03:02,790
so from eBGP from
other AS numbers--

57
00:03:02,790 --> 00:03:07,110
if we want to select a
specific exit for those routes,

58
00:03:07,110 --> 00:03:10,470
we would want to set the local
preference as those routes are

59
00:03:10,470 --> 00:03:13,320
coming in to the AS.

60
00:03:13,320 --> 00:03:16,500
Also, if we need to set a
preference on routes that

61
00:03:16,500 --> 00:03:19,020
are being redistributed,
we should do that

62
00:03:19,020 --> 00:03:21,390
at the point of redistribution.

63
00:03:21,390 --> 00:03:23,460
So essentially, what
we're saying here

64
00:03:23,460 --> 00:03:27,330
is we want to set the local
preference on the BGP update

65
00:03:27,330 --> 00:03:31,230
when it's introduced
to our BGP domain,

66
00:03:31,230 --> 00:03:34,350
either internally through
redistribution or maybe

67
00:03:34,350 --> 00:03:37,440
the network statement or
when we bring the routes

68
00:03:37,440 --> 00:03:40,710
in from an outside AS.

69
00:03:40,710 --> 00:03:44,760
Now, this is a well-known
and discretionary attribute--

70
00:03:44,760 --> 00:03:48,000
well-known meaning that
everybody who supports BGP

71
00:03:48,000 --> 00:03:49,920
will support local preference.

72
00:03:49,920 --> 00:03:52,410
Discretionary means
you don't have

73
00:03:52,410 --> 00:03:56,110
to set it if you don't
want to use this feature.

74
00:03:56,110 --> 00:03:59,670
Now, if we don't set it,
we'll talk about what happens.

75
00:03:59,670 --> 00:04:03,670
Also, as a note here,
this is a 32-bit value.

76
00:04:03,670 --> 00:04:06,420
So it's quite a bit larger
than weight, which remember,

77
00:04:06,420 --> 00:04:07,800
was 16 bit.

78
00:04:07,800 --> 00:04:11,250
But honestly, we don't really
need all those values anyway.

79
00:04:11,250 --> 00:04:14,500
It just happens to
be a 32-bit number.

80
00:04:14,500 --> 00:04:18,430
So what are the default
behaviors for local preference?

81
00:04:18,430 --> 00:04:23,320
Well, the default value
on Cisco equipment is 100.

82
00:04:23,320 --> 00:04:27,540
Now, you can change the
default local preference

83
00:04:27,540 --> 00:04:31,590
by using the bgp default
local-preference command.

84
00:04:31,590 --> 00:04:35,220
And that will change the
100 to, of course, whatever

85
00:04:35,220 --> 00:04:36,760
you decide to set it to.

86
00:04:36,760 --> 00:04:40,020
But if you leave it alone,
it will default to 100.

87
00:04:40,020 --> 00:04:43,950
Now, as far as default
behaviors based on prefixes,

88
00:04:43,950 --> 00:04:46,900
let's talk about each of these
a little bit differently.

89
00:04:46,900 --> 00:04:49,890
So first, we have
incoming prefixes.

90
00:04:49,890 --> 00:04:53,310
And this is simply going
to refer to prefixes

91
00:04:53,310 --> 00:04:56,220
being learned on this router.

92
00:04:56,220 --> 00:04:58,710
And there's three choices here.

93
00:04:58,710 --> 00:05:02,240
Choice number one is it
will apply the default.

94
00:05:02,240 --> 00:05:03,990
And again, it's talking
about this default

95
00:05:03,990 --> 00:05:07,840
up here when we reference
default at the bottom.

96
00:05:07,840 --> 00:05:11,560
So in this case, it would be
100, unless we change that.

97
00:05:11,560 --> 00:05:13,290
But this is what's
going to be applied

98
00:05:13,290 --> 00:05:17,790
to the external prefixes
as they come in from eBGP,

99
00:05:17,790 --> 00:05:20,610
because remember,
eBGP updates would not

100
00:05:20,610 --> 00:05:22,260
have a local preference on them.

101
00:05:22,260 --> 00:05:24,870
They don't carry
local preference.

102
00:05:24,870 --> 00:05:30,030
Option number two, we can
selectively set these values

103
00:05:30,030 --> 00:05:33,720
with a route map or
routing policy language,

104
00:05:33,720 --> 00:05:36,010
depending of course
on our platform.

105
00:05:36,010 --> 00:05:38,820
But we can of course
override the default

106
00:05:38,820 --> 00:05:41,370
on any prefixes we want to.

107
00:05:41,370 --> 00:05:43,330
The third choice
here, of course,

108
00:05:43,330 --> 00:05:47,580
is if it's coming from
iBGP, meaning it's already

109
00:05:47,580 --> 00:05:51,270
internal inside of
my BGP domain, well,

110
00:05:51,270 --> 00:05:54,090
I'll simply accept
the local preference

111
00:05:54,090 --> 00:05:55,770
that's already on it.

112
00:05:55,770 --> 00:05:57,610
There would be no
need to change it.

113
00:05:57,610 --> 00:06:00,600
However, if you do
need to change it,

114
00:06:00,600 --> 00:06:05,040
you certainly can using
the route map or RPL,

115
00:06:05,040 --> 00:06:07,080
because notice this
is saying that it's

116
00:06:07,080 --> 00:06:11,940
going to accept it only if
there is no route map or RPL

117
00:06:11,940 --> 00:06:13,290
on the update.

118
00:06:13,290 --> 00:06:17,710
So assuming there is not one,
then we accept the value.

119
00:06:17,710 --> 00:06:20,730
Now, for prefixes
that we're sending--

120
00:06:20,730 --> 00:06:25,770
so outgoing prefixes-- the only
way this is going to be set

121
00:06:25,770 --> 00:06:30,090
is with that route map or RPL.

122
00:06:30,090 --> 00:06:31,490
That's the only choice.

123
00:06:31,490 --> 00:06:35,190
Otherwise, there is no
just default behavior.

124
00:06:35,190 --> 00:06:38,990
Now, for routes that we
are redistributing into BGP

125
00:06:38,990 --> 00:06:42,980
on the local device, well,
once again, the default

126
00:06:42,980 --> 00:06:46,730
is going to be applied, assuming
that you do nothing else.

127
00:06:46,730 --> 00:06:49,520
Or once again, we can
selectively set it

128
00:06:49,520 --> 00:06:53,210
with the route map or RPL.

129
00:06:53,210 --> 00:06:56,900
So those are our choices
based on which direction

130
00:06:56,900 --> 00:06:58,860
the prefix is going.

131
00:06:58,860 --> 00:07:02,670
So now let's take a look at how
this would work in a scenario.

132
00:07:02,670 --> 00:07:05,060
So here we have a
very similar scenario

133
00:07:05,060 --> 00:07:08,210
that we used during weight
where we have two AS

134
00:07:08,210 --> 00:07:10,530
numbers connected by two links.

135
00:07:10,530 --> 00:07:13,280
One is a 10 gig,
and one is a 1 gig.

136
00:07:13,280 --> 00:07:17,300
And our goal here is
going to be to prefer

137
00:07:17,300 --> 00:07:22,520
the 10-gig link for our
traffic going to AS 200.

138
00:07:22,520 --> 00:07:25,070
Well, the nice thing
about local preference

139
00:07:25,070 --> 00:07:30,200
is all we have to do to get
this to work is on router one,

140
00:07:30,200 --> 00:07:33,290
for the prefixes learned
from router three,

141
00:07:33,290 --> 00:07:35,660
we simply set the
local preference

142
00:07:35,660 --> 00:07:39,620
to be 200 on those paths.

143
00:07:39,620 --> 00:07:43,970
That 200 is then going to be
passed down to router two.

144
00:07:43,970 --> 00:07:49,700
Router two is also going to
learn a local preference of 200

145
00:07:49,700 --> 00:07:53,030
for the prefixes going
towards router one

146
00:07:53,030 --> 00:07:58,850
where it would have the default
local preference of 100 going

147
00:07:58,850 --> 00:08:00,530
towards router four.

148
00:08:00,530 --> 00:08:04,190
So even though, by
normal BGP rules,

149
00:08:04,190 --> 00:08:07,460
router two should prefer the
external route going to router

150
00:08:07,460 --> 00:08:09,920
four, now it's not going to.

151
00:08:09,920 --> 00:08:12,590
It's going to go with the
highest local preference.

152
00:08:12,590 --> 00:08:16,400
And once again, traffic would
then flow from router two

153
00:08:16,400 --> 00:08:20,650
to router one and from
router one to router three,

154
00:08:20,650 --> 00:08:23,030
getting into AS 200.

155
00:08:23,030 --> 00:08:27,920
Therefore, we've selected
our exit from AS 100.

156
00:08:27,920 --> 00:08:30,230
And of course, the
nice thing about this,

157
00:08:30,230 --> 00:08:33,169
as opposed to
weight, we only had

158
00:08:33,169 --> 00:08:35,659
to configure one router here.

159
00:08:35,659 --> 00:08:37,580
We configured router one.

160
00:08:37,580 --> 00:08:40,580
We set that local
preference to 200.

161
00:08:40,580 --> 00:08:44,810
And that's the only place we
had to do any modifications

162
00:08:44,810 --> 00:08:47,700
to influence this path.

163
00:08:47,700 --> 00:08:52,130
So in this video, we saw
how to use local preference,

164
00:08:52,130 --> 00:08:55,790
much like we saw how to
use weight to influence

165
00:08:55,790 --> 00:08:58,850
the traffic leaving an AS.

166
00:08:58,850 --> 00:09:01,710
Now, again, with
things like community,

167
00:09:01,710 --> 00:09:04,160
it could be used to
affect the return path,

168
00:09:04,160 --> 00:09:06,180
but we'll talk about that later.

169
00:09:06,180 --> 00:09:08,090
The main thing to
take away from this

170
00:09:08,090 --> 00:09:10,100
is local preference
does sort of have

171
00:09:10,100 --> 00:09:12,140
two advantages over weight.

172
00:09:12,140 --> 00:09:14,750
The first is that it's
industry standard.

173
00:09:14,750 --> 00:09:19,850
It's part of BGP and,
therefore, is sent to neighbors.

174
00:09:19,850 --> 00:09:22,790
And while that brings
us to number two, which

175
00:09:22,790 --> 00:09:24,800
is directly related
to number one,

176
00:09:24,800 --> 00:09:27,140
that means that we
can use it to build

177
00:09:27,140 --> 00:09:31,370
a consistent routing policy
for our whole AS or domain.

178
00:09:31,370 --> 00:09:35,120
And we don't have to go
configure every single device

179
00:09:35,120 --> 00:09:38,450
individually like
we did with weight.

180
00:09:38,450 --> 00:09:40,670
I hope this has been
informative for you,

181
00:09:40,670 --> 00:09:43,810
and I'd like to thank
you for viewing.

182
00:09:43,810 --> 00:09:47,000