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

2
00:00:03,944 --> 00:00:07,890

3
00:00:07,890 --> 00:00:11,340
So now that we've seen weight
in action, now let's jump in

4
00:00:11,340 --> 00:00:14,280
and take a look at
local preference.

5
00:00:14,280 --> 00:00:17,070
In a lot of ways, these
are a bit similar,

6
00:00:17,070 --> 00:00:19,650
meaning that highest wins.

7
00:00:19,650 --> 00:00:22,980
They're going to affect our
outbound routing decisions.

8
00:00:22,980 --> 00:00:26,590
And we're going to set them
in a very similar fashion.

9
00:00:26,590 --> 00:00:28,360
But the main
difference, of course,

10
00:00:28,360 --> 00:00:31,710
is that weight only affects
the local router, where

11
00:00:31,710 --> 00:00:36,090
local preference will
affect the entire AS.

12
00:00:36,090 --> 00:00:38,500
So as we jump in to
look at our example,

13
00:00:38,500 --> 00:00:41,820
we're going to be affecting
an entire AS's decision

14
00:00:41,820 --> 00:00:45,420
to get to a destination
and, at the same time,

15
00:00:45,420 --> 00:00:47,740
only configure one router.

16
00:00:47,740 --> 00:00:50,580
So let's jump into our
topology, take a look

17
00:00:50,580 --> 00:00:52,622
at what our game
plan is going to be,

18
00:00:52,622 --> 00:00:54,330
and then we'll jump
into the command line

19
00:00:54,330 --> 00:00:57,340
and make it happen.

20
00:00:57,340 --> 00:00:59,460
So for this
demonstration, we're going

21
00:00:59,460 --> 00:01:03,600
to be looking at a route that's
actually coming from router

22
00:01:03,600 --> 00:01:07,120
8 being sent over to router 7.

23
00:01:07,120 --> 00:01:11,020
And as it is right
now, AS 100 over here

24
00:01:11,020 --> 00:01:14,800
should currently be
exiting through router 1,

25
00:01:14,800 --> 00:01:19,840
except router 3, which should
be going to router 7 directly.

26
00:01:19,840 --> 00:01:22,120
That decision we're
going to be keeping.

27
00:01:22,120 --> 00:01:24,880
But what we want to do
with our local preference

28
00:01:24,880 --> 00:01:28,060
is we want to change this
so all of the routers,

29
00:01:28,060 --> 00:01:34,291
including router 1, switch over
and start going to router 3.

30
00:01:34,291 --> 00:01:37,210
We're going to be doing
this by simply changing

31
00:01:37,210 --> 00:01:41,560
the policy on router 3 itself.

32
00:01:41,560 --> 00:01:44,350
Something else to keep in
mind as we're jumping in

33
00:01:44,350 --> 00:01:50,730
and begin looking at all of
this, router 1 and router 2

34
00:01:50,730 --> 00:01:54,030
are both configured
as route reflectors

35
00:01:54,030 --> 00:01:56,920
in a redundant cluster.

36
00:01:56,920 --> 00:02:01,170
So just keep this in mind, as
we jump into the command line,

37
00:02:01,170 --> 00:02:03,660
we will see some
evidence of this

38
00:02:03,660 --> 00:02:06,630
when we see how the updates
are being propagated

39
00:02:06,630 --> 00:02:11,400
as well as we'll see things such
as the cluster list in our BGP

40
00:02:11,400 --> 00:02:12,190
updates.

41
00:02:12,190 --> 00:02:15,000
So just again, keep
this in mind as we

42
00:02:15,000 --> 00:02:17,160
jump into the command
line and begin

43
00:02:17,160 --> 00:02:19,180
to implement our game plan.

44
00:02:19,180 --> 00:02:20,940
So let's go ahead
and do just that.

45
00:02:20,940 --> 00:02:23,840

46
00:02:23,840 --> 00:02:25,990
So let's just start on
router 1 with doing a show

47
00:02:25,990 --> 00:02:29,980
bgp for the 100.8.8.0 prefix.

48
00:02:29,980 --> 00:02:32,510
We see that we're
receiving multiple paths.

49
00:02:32,510 --> 00:02:34,810
However, we can see
that we're currently

50
00:02:34,810 --> 00:02:41,440
following the path from router
7 going external to our AS.

51
00:02:41,440 --> 00:02:44,290
Let's take a look at
what router 2 is doing.

52
00:02:44,290 --> 00:02:47,530
Now, router 2, we can see
here, has a rather interesting

53
00:02:47,530 --> 00:02:48,820
problem.

54
00:02:48,820 --> 00:02:53,800
Yes, it's currently using the
best path going to router 1,

55
00:02:53,800 --> 00:02:56,290
but that's not even the issue.

56
00:02:56,290 --> 00:03:00,370
It's receiving the
update from router 3.

57
00:03:00,370 --> 00:03:06,790
However, it still has a next hop
of 10.7.7.7, which is currently

58
00:03:06,790 --> 00:03:08,410
inaccessible.

59
00:03:08,410 --> 00:03:10,780
Keep in mind that
no matter what we

60
00:03:10,780 --> 00:03:15,070
do with policy, if the
next hop is inaccessible,

61
00:03:15,070 --> 00:03:17,830
there's no way router
2 is ever going

62
00:03:17,830 --> 00:03:20,450
to use this particular path.

63
00:03:20,450 --> 00:03:23,350
So we're going to have
to fix this first.

64
00:03:23,350 --> 00:03:25,510
But before we do,
let's still hop over

65
00:03:25,510 --> 00:03:30,200
to router 4 and see what its
current path selection is.

66
00:03:30,200 --> 00:03:33,710
So on router 4, looking
at the same prefix,

67
00:03:33,710 --> 00:03:36,860
we see that it has learned this
information from both route

68
00:03:36,860 --> 00:03:43,370
reflectors, both with the next
hop of router 1, the 10.1.1.1.

69
00:03:43,370 --> 00:03:48,260
So aside from router 3
itself, nobody else in AS 100

70
00:03:48,260 --> 00:03:50,870
is using router 3 as the exit.

71
00:03:50,870 --> 00:03:53,120
But before we can
make it do so, we

72
00:03:53,120 --> 00:03:58,580
have to fix that next
hop issue on router 3.

73
00:03:58,580 --> 00:04:03,200
So what we need to do is
go into router bgp 100,

74
00:04:03,200 --> 00:04:07,010
go into neighbor 10.1.1.1
for the address family

75
00:04:07,010 --> 00:04:09,110
ipv4 unicast.

76
00:04:09,110 --> 00:04:11,810
And we'll simply
say next-hop-self.

77
00:04:11,810 --> 00:04:14,870
We'll do the same
thing for router 2.

78
00:04:14,870 --> 00:04:16,610
Commit the changes.

79
00:04:16,610 --> 00:04:19,019
And exit configuration.

80
00:04:19,019 --> 00:04:21,890
Now let's go over and
verify that router 2

81
00:04:21,890 --> 00:04:24,680
has the prefix correctly now.

82
00:04:24,680 --> 00:04:28,040
So on router 2, we'll simply
repeat the last command there.

83
00:04:28,040 --> 00:04:31,880
And we can see that now, even
though we're not using it

84
00:04:31,880 --> 00:04:35,270
at the moment, it's at
least receiving the update

85
00:04:35,270 --> 00:04:39,850
from router 3 with a
next hop of router 3.

86
00:04:39,850 --> 00:04:43,740
And it's no longer
listed as inaccessible.

87
00:04:43,740 --> 00:04:46,710
So now, as long as
we change our policy

88
00:04:46,710 --> 00:04:48,960
to make this the
best route, using,

89
00:04:48,960 --> 00:04:51,210
of course, local
preference, now it

90
00:04:51,210 --> 00:04:53,340
can actually choose
it and use it

91
00:04:53,340 --> 00:04:56,070
because it's no
longer inaccessible.

92
00:04:56,070 --> 00:04:58,420
So let's go ahead
and do just that.

93
00:04:58,420 --> 00:05:02,220
Again, this policy is going
to be done on router 3.

94
00:05:02,220 --> 00:05:06,000
So the first thing we'll
do is create a prefix set.

95
00:05:06,000 --> 00:05:07,650
We don't necessarily need this.

96
00:05:07,650 --> 00:05:10,170
We could do it on all routes.

97
00:05:10,170 --> 00:05:13,020
But we'll pick on just the one
we're supposed to be doing.

98
00:05:13,020 --> 00:05:16,320
We'll call this PS_FROM_R7.

99
00:05:16,320 --> 00:05:21,630
And it's going to match
on the 100.8.8.0/24.

100
00:05:21,630 --> 00:05:23,250
We'll end the set.

101
00:05:23,250 --> 00:05:25,350
Then we'll create
a route policy.

102
00:05:25,350 --> 00:05:28,950
We'll also just
call this FROM R7.

103
00:05:28,950 --> 00:05:30,900
And we'll set our policy.

104
00:05:30,900 --> 00:05:36,870
We'll say, if destination
is in our prefix set,

105
00:05:36,870 --> 00:05:41,860
then what we're going to do
is set the local-preference.

106
00:05:41,860 --> 00:05:46,350
Now, remember, this is the
path that we want to use.

107
00:05:46,350 --> 00:05:49,920
Highest local preference
wins, and the default

108
00:05:49,920 --> 00:05:52,990
local preference is 100.

109
00:05:52,990 --> 00:05:56,670
So what we need to do here is
set this literally to any value

110
00:05:56,670 --> 00:05:58,080
higher than 100--

111
00:05:58,080 --> 00:06:00,510
so 101, 150.

112
00:06:00,510 --> 00:06:02,040
We're just going to do 200.

113
00:06:02,040 --> 00:06:03,510
It's just a quick, easy number.

114
00:06:03,510 --> 00:06:06,780
But really, any number
higher than the default.

115
00:06:06,780 --> 00:06:10,830
If we were trying to get
it not to use this path,

116
00:06:10,830 --> 00:06:12,720
then we'd go the other way.

117
00:06:12,720 --> 00:06:16,500
We would set the local
preference somewhere below 100.

118
00:06:16,500 --> 00:06:20,160
So realistically, we
could have implemented

119
00:06:20,160 --> 00:06:24,780
our overall policy
on router 1 instead

120
00:06:24,780 --> 00:06:27,660
and lowered the
local preference.

121
00:06:27,660 --> 00:06:30,360
But we did say during
our game plan that we

122
00:06:30,360 --> 00:06:33,280
were going to do this on
router 3-- so in which case,

123
00:06:33,280 --> 00:06:36,120
we'll set this to a
local preference of 200.

124
00:06:36,120 --> 00:06:37,710
So we'll set the 200.

125
00:06:37,710 --> 00:06:42,750
Then tell it to pass the
routes through, and else pass,

126
00:06:42,750 --> 00:06:46,410
because again, we're not
trying to use this as a filter.

127
00:06:46,410 --> 00:06:48,420
We'll end our if statement.

128
00:06:48,420 --> 00:06:50,650
We'll end our policy.

129
00:06:50,650 --> 00:06:55,240
We're go into BGP for
router 7, of course,

130
00:06:55,240 --> 00:06:57,180
in our address-family.

131
00:06:57,180 --> 00:07:01,530
And we're going to say,
route-policy RP_FROM_R7.

132
00:07:01,530 --> 00:07:04,880
And of course, this
would be inbound.

133
00:07:04,880 --> 00:07:07,357
Now, before we
commit this change,

134
00:07:07,357 --> 00:07:09,440
I just want to show you
something very interesting

135
00:07:09,440 --> 00:07:12,020
that IOS XR does for us.

136
00:07:12,020 --> 00:07:15,080
Let's get a Wireshark
capture going

137
00:07:15,080 --> 00:07:19,490
of the interface between
router 3 and router 7,

138
00:07:19,490 --> 00:07:21,950
looking at BGP traffic.

139
00:07:21,950 --> 00:07:24,830
Specifically, we're going to
be looking for route refresh

140
00:07:24,830 --> 00:07:25,640
messages.

141
00:07:25,640 --> 00:07:29,730
Let's get that Wireshark
capture set up.

142
00:07:29,730 --> 00:07:31,880
So here we have
our capture running

143
00:07:31,880 --> 00:07:36,170
with our specific
filter to allow for BGP

144
00:07:36,170 --> 00:07:39,230
unless the length is 19.

145
00:07:39,230 --> 00:07:43,380
Once again, this should
keep out the keep-alives.

146
00:07:43,380 --> 00:07:47,730
So this is going to capture
just other BGP traffic.

147
00:07:47,730 --> 00:07:51,210
Now let's go commit our change.

148
00:07:51,210 --> 00:07:53,210
So we'll commit our change.

149
00:07:53,210 --> 00:07:54,750
Exit configuration.

150
00:07:54,750 --> 00:07:59,160
And let's go back and
look at Wireshark.

151
00:07:59,160 --> 00:08:02,670
Notice that as soon as we
applied that configuration

152
00:08:02,670 --> 00:08:06,840
change or policy
change on IOS XR,

153
00:08:06,840 --> 00:08:11,850
it automatically does
that route refresh for us.

154
00:08:11,850 --> 00:08:16,200
If you remember, when we were
talking about route refresh,

155
00:08:16,200 --> 00:08:19,080
we mentioned that this
is a manual process

156
00:08:19,080 --> 00:08:20,740
that you have to trigger it.

157
00:08:20,740 --> 00:08:24,030
And on IOS XE, that's
definitely true.

158
00:08:24,030 --> 00:08:28,890
On IOS XR, it will
usually detect

159
00:08:28,890 --> 00:08:31,290
that you've applied
a policy change

160
00:08:31,290 --> 00:08:34,260
and therefore do
a route refresh.

161
00:08:34,260 --> 00:08:36,190
If not, you can
always, of course,

162
00:08:36,190 --> 00:08:41,350
do it manually if your
changes don't take effect.

163
00:08:41,350 --> 00:08:44,490
But now that we saw that it
actually did a route refresh,

164
00:08:44,490 --> 00:08:47,070
let's go ahead back
over to the command line

165
00:08:47,070 --> 00:08:49,470
then and see if our
local preference

166
00:08:49,470 --> 00:08:51,970
changes have taken effect.

167
00:08:51,970 --> 00:08:55,350
So let's go back to our other
routers and check it out.

168
00:08:55,350 --> 00:09:00,240
Router 1, let's go ahead and
look at our show bgp again.

169
00:09:00,240 --> 00:09:03,810
And we see right here
that the path learned

170
00:09:03,810 --> 00:09:07,440
from router 3 going
through router 3 now

171
00:09:07,440 --> 00:09:10,620
has a local preference of 200.

172
00:09:10,620 --> 00:09:13,800
And it's selected as best.

173
00:09:13,800 --> 00:09:16,040
Let's check router 2.

174
00:09:16,040 --> 00:09:18,470
On router 2, we
see the same thing.

175
00:09:18,470 --> 00:09:22,700
It's learned from router 3
with the next hop of router 3.

176
00:09:22,700 --> 00:09:25,580
It has the local
preference of 200.

177
00:09:25,580 --> 00:09:28,250
And it's selected as best.

178
00:09:28,250 --> 00:09:30,650
Finally, let's check router 4.

179
00:09:30,650 --> 00:09:35,030
So as we see here on router
4, like previously, it

180
00:09:35,030 --> 00:09:39,800
learned a copy of this path
from both route reflectors,

181
00:09:39,800 --> 00:09:43,560
both going to router
3 as the next hop.

182
00:09:43,560 --> 00:09:47,630
And in this case, the
one from router 10.1.1.1

183
00:09:47,630 --> 00:09:49,610
was selected as best.

184
00:09:49,610 --> 00:09:54,170
But they both have a
local preference of 200.

185
00:09:54,170 --> 00:09:57,650
So we can see that local
preference is working exactly

186
00:09:57,650 --> 00:10:00,570
as we designed.

187
00:10:00,570 --> 00:10:06,300
In this video, we used local
preference on a single router

188
00:10:06,300 --> 00:10:12,150
to influence the BGP path
selection for the entire AS.

189
00:10:12,150 --> 00:10:15,930
And that really is the big
advantage of local preference

190
00:10:15,930 --> 00:10:18,310
over something like weight.

191
00:10:18,310 --> 00:10:22,030
Remember, weight is
first Cisco proprietary.

192
00:10:22,030 --> 00:10:26,340
But more importantly, it only
affects the local router, which

193
00:10:26,340 --> 00:10:30,360
means if I wanted to make
this same change using weight,

194
00:10:30,360 --> 00:10:33,870
I would have had to have
gone to all four routers

195
00:10:33,870 --> 00:10:35,650
and made that change.

196
00:10:35,650 --> 00:10:39,650
In this case, I made
one change on router 3,

197
00:10:39,650 --> 00:10:41,880
not counting changing
the next hop,

198
00:10:41,880 --> 00:10:45,195
but one change to our
policy on router 3

199
00:10:45,195 --> 00:10:49,500
to set that local preference to
200, higher than the default,

200
00:10:49,500 --> 00:10:52,200
to get us to prefer that path.

201
00:10:52,200 --> 00:10:54,480
I hope this has been
informative for you,

202
00:10:54,480 --> 00:10:57,650
and I'd like to thank
you for viewing.

203
00:10:57,650 --> 00:11:01,334