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

2
00:00:03,437 --> 00:00:07,860

3
00:00:07,860 --> 00:00:11,580
So now that we've explored
soft reconfiguration and route

4
00:00:11,580 --> 00:00:14,520
refresh, now let's
actually start

5
00:00:14,520 --> 00:00:18,210
implementing some of our
BGP path selection features.

6
00:00:18,210 --> 00:00:21,150
In this video, we'll
start with weight.

7
00:00:21,150 --> 00:00:23,440
Weight, of course,
as we mentioned,

8
00:00:23,440 --> 00:00:25,810
is local just to this router.

9
00:00:25,810 --> 00:00:30,780
So let's take a look at
configuring this on IOS XE

10
00:00:30,780 --> 00:00:33,300
as well as IOS RE.

11
00:00:33,300 --> 00:00:35,280
We'll start by bringing
up our topology

12
00:00:35,280 --> 00:00:36,990
and putting together
a game plan.

13
00:00:36,990 --> 00:00:38,850
And then we'll jump
into the command line

14
00:00:38,850 --> 00:00:42,520
and see weight in action.

15
00:00:42,520 --> 00:00:46,050
So we'll go ahead
and start on IOS XE.

16
00:00:46,050 --> 00:00:49,290
So for that, let's go
ahead and work on router 7.

17
00:00:49,290 --> 00:00:53,100
And what we're going to be
looking for is on router 7

18
00:00:53,100 --> 00:00:55,540
right now there should
be a default route,

19
00:00:55,540 --> 00:00:58,860
which is currently
pointing to router 1.

20
00:00:58,860 --> 00:01:02,050
And we're going to
override that, of course,

21
00:01:02,050 --> 00:01:05,160
using the weight
attribute, and instead

22
00:01:05,160 --> 00:01:08,520
let's get that traffic
to go and use the default

23
00:01:08,520 --> 00:01:11,310
route from router 6.

24
00:01:11,310 --> 00:01:15,780
Now, ultimately, router 6 will
still forward that traffic

25
00:01:15,780 --> 00:01:17,130
to router 1.

26
00:01:17,130 --> 00:01:19,980
But we're not too worried
about the data plane right now.

27
00:01:19,980 --> 00:01:22,390
We're not worried
about the overall path.

28
00:01:22,390 --> 00:01:25,500
So let's jump into the command
line and implement this.

29
00:01:25,500 --> 00:01:28,980
We'll start off by looking at
the current default on router

30
00:01:28,980 --> 00:01:30,900
7.

31
00:01:30,900 --> 00:01:33,732
So we'll do a sh ip
bgp to begin with.

32
00:01:33,732 --> 00:01:35,190
And the first thing
we want to note

33
00:01:35,190 --> 00:01:37,590
is that we are, in fact,
learning the default route

34
00:01:37,590 --> 00:01:39,810
across three different paths.

35
00:01:39,810 --> 00:01:46,350
Currently the best is selected
as the 50.0.167.1, which

36
00:01:46,350 --> 00:01:50,100
is, of course, router 1 being
the next hop going directly

37
00:01:50,100 --> 00:01:55,290
to AS 100 and
ultimately to AS 300.

38
00:01:55,290 --> 00:01:56,820
We, of course, are
going to change

39
00:01:56,820 --> 00:02:03,630
this to prefer the path through
50.0.167.6, going through AS

40
00:02:03,630 --> 00:02:07,860
1000 and then 100 and then 300.

41
00:02:07,860 --> 00:02:11,890
So to do this, let's go ahead
and go into configuration mode.

42
00:02:11,890 --> 00:02:14,130
We will need a prefix list.

43
00:02:14,130 --> 00:02:17,670
We'll call it PL_FROM_R6.

44
00:02:17,670 --> 00:02:21,570
And we'll simply permit
the default route.

45
00:02:21,570 --> 00:02:23,760
Then we'll match on
that with a route map.

46
00:02:23,760 --> 00:02:27,510
We'll call it RM_FROM_R6.

47
00:02:27,510 --> 00:02:29,220
In our first
statement we'll simply

48
00:02:29,220 --> 00:02:33,390
say to match on the IP
address using the prefix list

49
00:02:33,390 --> 00:02:35,560
that we created earlier.

50
00:02:35,560 --> 00:02:40,040
Then we're going to set
the weight attribute.

51
00:02:40,040 --> 00:02:43,370
We can see here, based on
the context sensitive help,

52
00:02:43,370 --> 00:02:46,250
that this is in
fact a 16-bit value.

53
00:02:46,250 --> 00:02:50,720
And we can put in
anything 0 through 65535.

54
00:02:50,720 --> 00:02:52,970
Given that the
default for this path

55
00:02:52,970 --> 00:02:57,380
is currently 0 and
highest weight wins,

56
00:02:57,380 --> 00:03:00,120
we can pretty much put
in any weight we want.

57
00:03:00,120 --> 00:03:03,020
So let's just put in like 100.

58
00:03:03,020 --> 00:03:07,010
Now let's go into
router bgp 65001.

59
00:03:07,010 --> 00:03:13,790
And on our neighbor 50.0.167.6,
note that if we wanted to,

60
00:03:13,790 --> 00:03:16,810
we could, in fact, set
the weight right here.

61
00:03:16,810 --> 00:03:21,390
We don't need to use the
prefix list and the route map.

62
00:03:21,390 --> 00:03:25,470
Personally, I usually go
right to setting attributes

63
00:03:25,470 --> 00:03:27,210
with a route map.

64
00:03:27,210 --> 00:03:30,510
In this particular
case, it might be easier

65
00:03:30,510 --> 00:03:34,530
to put the weight directly
on the neighbor statement.

66
00:03:34,530 --> 00:03:38,200
However, things generally
never stay simple.

67
00:03:38,200 --> 00:03:40,650
They usually get
more complicated.

68
00:03:40,650 --> 00:03:43,900
And this way we would already
have a route map built.

69
00:03:43,900 --> 00:03:46,620
And if we did need to
manipulate other things coming

70
00:03:46,620 --> 00:03:50,470
from router 6, we already
have that structure in place.

71
00:03:50,470 --> 00:03:53,190
So, yes, we could have done
it right here on the neighbor

72
00:03:53,190 --> 00:03:56,730
statement, but instead we're
going to apply that route map.

73
00:03:56,730 --> 00:04:01,315
So our route map was RM_FROM_R6.

74
00:04:01,315 --> 00:04:03,690
And, of course, you have to
choose which direction you're

75
00:04:03,690 --> 00:04:05,610
going to apply that route map.

76
00:04:05,610 --> 00:04:08,730
We're going to want to apply
this to updates coming in

77
00:04:08,730 --> 00:04:10,530
from router 6.

78
00:04:10,530 --> 00:04:13,050
We'll go ahead and exit
configuration mode.

79
00:04:13,050 --> 00:04:16,920
And note if we do
a sh ip bgp, notice

80
00:04:16,920 --> 00:04:18,390
that nothing's happened yet.

81
00:04:18,390 --> 00:04:20,700
All the weights are still 0.

82
00:04:20,700 --> 00:04:25,260
This, again, is because we need
to trigger a route refresh.

83
00:04:25,260 --> 00:04:29,820
So we'll just do a clear ip
bgp for router 6's neighborship

84
00:04:29,820 --> 00:04:31,260
inbound.

85
00:04:31,260 --> 00:04:34,230
Then we'll do our
show ip bgp again.

86
00:04:34,230 --> 00:04:37,230
Here we see that the
wait is now set properly

87
00:04:37,230 --> 00:04:41,370
to 100 on the prefix
coming from router 6.

88
00:04:41,370 --> 00:04:45,280
And, in fact, that is the
path that we are now using.

89
00:04:45,280 --> 00:04:49,660
So we can see that weight has
manipulated our path selection.

90
00:04:49,660 --> 00:04:55,200
We are now going through
router 6 and AS 1000, which

91
00:04:55,200 --> 00:04:57,730
was our stated design goal.

92
00:04:57,730 --> 00:05:00,660
So next let's look at IOS XR.

93
00:05:00,660 --> 00:05:03,540
But before we do,
we need to see what

94
00:05:03,540 --> 00:05:05,760
router 3-- which
is the router we're

95
00:05:05,760 --> 00:05:07,590
going to be
manipulating-- we need

96
00:05:07,590 --> 00:05:10,980
to see what it's already
doing before we can decide

97
00:05:10,980 --> 00:05:14,050
what choice we're going to make
as far as changing its path.

98
00:05:14,050 --> 00:05:17,470
So let's look at router 3.

99
00:05:17,470 --> 00:05:20,000
Let's do a show bgp.

100
00:05:20,000 --> 00:05:23,360
What we see here is that the
default route is currently

101
00:05:23,360 --> 00:05:25,820
going through router 1.

102
00:05:25,820 --> 00:05:28,040
So let's go back
over to our diagram

103
00:05:28,040 --> 00:05:31,188
and come up with a game plan
of what we're going to change.

104
00:05:31,188 --> 00:05:33,230
So we're going to be doing
something similar here

105
00:05:33,230 --> 00:05:34,820
to what we did on router 7.

106
00:05:34,820 --> 00:05:40,364
However, for IOS XR, we're
going to look at router 3.

107
00:05:40,364 --> 00:05:43,310
Currently as we
just saw, router 3

108
00:05:43,310 --> 00:05:46,280
is following a
default to router 1.

109
00:05:46,280 --> 00:05:48,980
That's the one we're not
going to want it to use.

110
00:05:48,980 --> 00:05:51,740
We're going to instead
want it to choose

111
00:05:51,740 --> 00:05:55,010
the default going to router 2.

112
00:05:55,010 --> 00:05:57,730
So that's the change that we're
going to make on router 3,

113
00:05:57,730 --> 00:06:01,620
again, of course, using weight.

114
00:06:01,620 --> 00:06:05,655
So here on router 3 we're
going to need a prefix set.

115
00:06:05,655 --> 00:06:09,180
We'll just call it PS_DEFAULT.

116
00:06:09,180 --> 00:06:12,150
We'll set this to match
on the default route.

117
00:06:12,150 --> 00:06:14,310
And we'll end the set.

118
00:06:14,310 --> 00:06:16,780
And then we're going
to need a route policy.

119
00:06:16,780 --> 00:06:19,965
So we'll create a route policy,
we'll call it RP_FROM_R2.

120
00:06:19,965 --> 00:06:22,980

121
00:06:22,980 --> 00:06:25,260
And then we'll start
writing our policy.

122
00:06:25,260 --> 00:06:32,940
We'll say if destination
is in the PS_DEFAULT,

123
00:06:32,940 --> 00:06:35,948
then what we're going
to do to this prefix,

124
00:06:35,948 --> 00:06:37,740
we're going to go ahead
and set the weight.

125
00:06:37,740 --> 00:06:39,420
We'll just use 100
again, but we can

126
00:06:39,420 --> 00:06:43,130
see it's, of course,
the same range.

127
00:06:43,130 --> 00:06:46,220
And then go ahead and
pass the route through.

128
00:06:46,220 --> 00:06:48,420
Then we'll say, else.

129
00:06:48,420 --> 00:06:52,430
So, of course, for anything
not matching our prefix set,

130
00:06:52,430 --> 00:06:55,760
we'll just pass those
routes through unchanged

131
00:06:55,760 --> 00:06:59,510
because our goal here
is not to filter routes,

132
00:06:59,510 --> 00:07:02,360
it's just to manipulate
the one route.

133
00:07:02,360 --> 00:07:04,550
We'll end our if statement.

134
00:07:04,550 --> 00:07:06,530
We'll end our policy.

135
00:07:06,530 --> 00:07:09,750
And then we'll go
into router bgp 100.

136
00:07:09,750 --> 00:07:11,840
We're going to say
for the nei 10.2.2.2,

137
00:07:11,840 --> 00:07:14,300
which is an already
preconfigured neighbor,

138
00:07:14,300 --> 00:07:17,630
for the address
family IPv4 unicast.

139
00:07:17,630 --> 00:07:20,930
Now, once again,
just like iOS XE,

140
00:07:20,930 --> 00:07:24,770
there is a choice here where
we can, again, set the weight

141
00:07:24,770 --> 00:07:26,900
directly on the neighborship.

142
00:07:26,900 --> 00:07:31,280
We didn't have to use a
prefix set and a route policy,

143
00:07:31,280 --> 00:07:34,730
it's just more flexible
moving forward.

144
00:07:34,730 --> 00:07:38,220
But we do still have to
apply that route policy.

145
00:07:38,220 --> 00:07:42,560
So we'll say
route-policy RP_FROM_R2.

146
00:07:42,560 --> 00:07:44,670
Once again, it's going
to need a direction.

147
00:07:44,670 --> 00:07:46,850
So we'll say in.

148
00:07:46,850 --> 00:07:51,350
We'll commit those changes,
and we'll exit configuration.

149
00:07:51,350 --> 00:07:54,230
Once again, if we
do a sh bgp, we

150
00:07:54,230 --> 00:07:56,250
can see that in this
particular case,

151
00:07:56,250 --> 00:07:58,790
it already changed the weight.

152
00:07:58,790 --> 00:08:01,220
If it hadn't, we
could, of course,

153
00:08:01,220 --> 00:08:03,210
clear this session again.

154
00:08:03,210 --> 00:08:06,020
But in this case,
it's already done so

155
00:08:06,020 --> 00:08:09,350
and we can see that the
weight is now set to 100.

156
00:08:09,350 --> 00:08:12,860
And we are now using the
path through 10.2.2.2,

157
00:08:12,860 --> 00:08:16,750
which was our goal.

158
00:08:16,750 --> 00:08:21,490
In this video, we looked at
how to use the bgp weight

159
00:08:21,490 --> 00:08:27,910
property to influence our
path selection on both IOS XR

160
00:08:27,910 --> 00:08:30,070
and IOS XE.

161
00:08:30,070 --> 00:08:35,200
Now as we saw, you can do this
directly under the neighborship

162
00:08:35,200 --> 00:08:38,590
properties as an
attribute, or you

163
00:08:38,590 --> 00:08:42,490
can do it either through
RPL or a route map.

164
00:08:42,490 --> 00:08:45,400
But, again, using RPL
with the route map

165
00:08:45,400 --> 00:08:47,920
is generally more
flexible moving forward

166
00:08:47,920 --> 00:08:51,550
since things don't always
stay quite so simple.

167
00:08:51,550 --> 00:08:53,770
I hope this has been
informative for you,

168
00:08:53,770 --> 00:08:56,940
and I'd like to thank
you for viewing.

169
00:08:56,940 --> 00:09:00,000