1
00:00:00,000 --> 00:00:00,968

2
00:00:00,968 --> 00:00:04,356
[AUDIO LOGO]

3
00:00:04,356 --> 00:00:07,260

4
00:00:07,260 --> 00:00:09,570
Now that we've gotten
a little more familiar

5
00:00:09,570 --> 00:00:13,620
with the overall BGP
path selection process,

6
00:00:13,620 --> 00:00:16,680
let's jump in and
take a closer look

7
00:00:16,680 --> 00:00:20,610
at Cisco's proprietary
weight feature.

8
00:00:20,610 --> 00:00:24,450
We can't exactly call
this a BGP attribute

9
00:00:24,450 --> 00:00:29,130
since it is Cisco proprietary
and as such is not

10
00:00:29,130 --> 00:00:31,710
carried in BGP updates.

11
00:00:31,710 --> 00:00:34,770
Therefore, it's not
truly an attribute.

12
00:00:34,770 --> 00:00:40,680
However, it is at the very top
of the path selection criteria,

13
00:00:40,680 --> 00:00:44,910
making this a very critical
part of our path selection

14
00:00:44,910 --> 00:00:46,120
decisions.

15
00:00:46,120 --> 00:00:48,750
So let's jump in and
take a look at some

16
00:00:48,750 --> 00:00:51,210
of the attributes
of weight and how

17
00:00:51,210 --> 00:00:56,300
we can use this to affect
our path selection.

18
00:00:56,300 --> 00:00:58,690
So the first thing
here, as we mentioned

19
00:00:58,690 --> 00:01:02,890
during the introduction,
this falls under BGP rule

20
00:01:02,890 --> 00:01:06,010
number 1 that we're
going to prefer the path

21
00:01:06,010 --> 00:01:08,800
with the highest weight.

22
00:01:08,800 --> 00:01:11,680
So that's just a
reminder of which rule

23
00:01:11,680 --> 00:01:13,700
we're speaking of here.

24
00:01:13,700 --> 00:01:16,660
Let's talk about some
things about this rule.

25
00:01:16,660 --> 00:01:21,440
First, this is going to be
used for outbound decisions.

26
00:01:21,440 --> 00:01:24,430
And the reason it's going to
be outbound decisions is it

27
00:01:24,430 --> 00:01:28,070
can only affect
the local router.

28
00:01:28,070 --> 00:01:30,040
Now, if it can only
affect the local router,

29
00:01:30,040 --> 00:01:32,530
that means it can only
affect its decisions

30
00:01:32,530 --> 00:01:35,590
and that would mean
outbound decisions.

31
00:01:35,590 --> 00:01:41,360
You can't influence return
traffic with weight.

32
00:01:41,360 --> 00:01:43,850
Now, let me add one
little note here.

33
00:01:43,850 --> 00:01:46,850
When we say you can't do
something with weight,

34
00:01:46,850 --> 00:01:51,050
for example, I simply mean
you can't do it directly

35
00:01:51,050 --> 00:01:52,138
with weight.

36
00:01:52,138 --> 00:01:54,680
A little bit later, we're going
to be talking about something

37
00:01:54,680 --> 00:01:56,870
called BGP communities.

38
00:01:56,870 --> 00:02:01,700
And we could use communities
to trigger another router

39
00:02:01,700 --> 00:02:04,070
to change its weight.

40
00:02:04,070 --> 00:02:06,800
But that's not
exactly using weight.

41
00:02:06,800 --> 00:02:09,440
It's using something
else to trigger

42
00:02:09,440 --> 00:02:11,670
the attribute being changed.

43
00:02:11,670 --> 00:02:14,220
So that's not exactly
the same thing.

44
00:02:14,220 --> 00:02:18,650
So can we use this in
conjunction with communities?

45
00:02:18,650 --> 00:02:19,400
Yes.

46
00:02:19,400 --> 00:02:22,130
And we'll talk about that
when we get to communities.

47
00:02:22,130 --> 00:02:25,160
But for now, weight
is only going

48
00:02:25,160 --> 00:02:28,460
to affect the local
routers decisions.

49
00:02:28,460 --> 00:02:31,790
And as such, that
means outbound.

50
00:02:31,790 --> 00:02:35,450
Again, as we've mentioned,
this is Cisco proprietary.

51
00:02:35,450 --> 00:02:38,760
That is why we refer to
it more as a feature.

52
00:02:38,760 --> 00:02:41,720
So this is not a BGP attribute.

53
00:02:41,720 --> 00:02:46,670
This is not carried in
any of the BGP updates.

54
00:02:46,670 --> 00:02:49,640
And as we mentioned,
since it's not carried,

55
00:02:49,640 --> 00:02:53,870
that means that it's going
to, of course, be local only.

56
00:02:53,870 --> 00:02:58,040
And as that implies, it
is never sent to peers.

57
00:02:58,040 --> 00:03:01,250
Again, what if I tried to
send it to a non-Cisco router?

58
00:03:01,250 --> 00:03:03,440
It wouldn't even
know what this meant.

59
00:03:03,440 --> 00:03:06,780
And since all the other devices
wouldn't understand this

60
00:03:06,780 --> 00:03:09,150
and we don't send
it to them anyway,

61
00:03:09,150 --> 00:03:11,540
that makes it really
difficult to try

62
00:03:11,540 --> 00:03:16,070
to use this for any kind of
a consistent routing policy

63
00:03:16,070 --> 00:03:18,210
through our BGP domain.

64
00:03:18,210 --> 00:03:21,140
So this is really
not the best choice

65
00:03:21,140 --> 00:03:24,620
if we want to come up
with a universal policy

66
00:03:24,620 --> 00:03:26,400
for our domain.

67
00:03:26,400 --> 00:03:28,490
So what is it good for then?

68
00:03:28,490 --> 00:03:31,550
Well, its main
function is it gives us

69
00:03:31,550 --> 00:03:34,200
a way to allow a router.

70
00:03:34,200 --> 00:03:37,640
So we're talking about a
single entity that might itself

71
00:03:37,640 --> 00:03:42,110
have multiple exits to make
a decision as to which exit

72
00:03:42,110 --> 00:03:45,980
to use, either without
using local preference

73
00:03:45,980 --> 00:03:50,830
or to override whatever local
preference may be set to.

74
00:03:50,830 --> 00:03:56,650
The idea here is I can use
this to override the normal BGP

75
00:03:56,650 --> 00:04:01,330
policy in my domain on
any one specific device

76
00:04:01,330 --> 00:04:05,260
if I want that device to make a
different decision for whatever

77
00:04:05,260 --> 00:04:06,680
reason.

78
00:04:06,680 --> 00:04:09,890
Now, we mentioned that the
highest value here wins.

79
00:04:09,890 --> 00:04:14,440
And it has a range
of 0 to 65535.

80
00:04:14,440 --> 00:04:17,779
This is a 16-bit number.

81
00:04:17,779 --> 00:04:22,900
So what happens with weight by
default if we don't control it?

82
00:04:22,900 --> 00:04:27,640
Well, locally injected routes
and redistributed internal

83
00:04:27,640 --> 00:04:31,450
prefixes are going to
default right into the middle

84
00:04:31,450 --> 00:04:38,500
32768, half way between
our 0 and our 65535.

85
00:04:38,500 --> 00:04:42,520
Any learned prefixes,
so something sent to us

86
00:04:42,520 --> 00:04:47,620
by another device, will
default to a weight of 0,

87
00:04:47,620 --> 00:04:50,260
which, of course,
since highest wins,

88
00:04:50,260 --> 00:04:53,270
would make this the worst value.

89
00:04:53,270 --> 00:04:55,780
Now, of course, as
administrators, we

90
00:04:55,780 --> 00:04:58,660
can take control of
weight and we can either

91
00:04:58,660 --> 00:05:01,240
set this just per
neighbor if we're

92
00:05:01,240 --> 00:05:05,020
looking for a very simplified
decision, such as always

93
00:05:05,020 --> 00:05:08,740
preferring a primary
path over a backup path.

94
00:05:08,740 --> 00:05:11,570
Or, if we want to
get more complicated,

95
00:05:11,570 --> 00:05:15,550
we can use a route map or
a routing policy language

96
00:05:15,550 --> 00:05:18,760
for more complex
situations where

97
00:05:18,760 --> 00:05:23,330
I could actually set the
weight individually per prefix.

98
00:05:23,330 --> 00:05:26,110
So let's bring up a
real simple topology

99
00:05:26,110 --> 00:05:28,600
and just talk for a moment
about how we could use

100
00:05:28,600 --> 00:05:31,340
this to influence our routing.

101
00:05:31,340 --> 00:05:37,120
So let's talk about traffic
going from AS 100 to AS 200.

102
00:05:37,120 --> 00:05:39,580
And we have these two links
that are connecting the two

103
00:05:39,580 --> 00:05:41,180
ASs together.

104
00:05:41,180 --> 00:05:43,430
So just for the
sake of argument,

105
00:05:43,430 --> 00:05:46,540
let's say that this link
down here at the bottom

106
00:05:46,540 --> 00:05:50,920
is a 1 gig link and our
link up here at the top

107
00:05:50,920 --> 00:05:52,870
is a 10 gig link.

108
00:05:52,870 --> 00:05:58,550
So our preference is going
to be to use the 10 gig link.

109
00:05:58,550 --> 00:06:02,590
So let's start by talking about
what we can do on router 1.

110
00:06:02,590 --> 00:06:07,810
What we could do is on the
neighborship towards router 2,

111
00:06:07,810 --> 00:06:11,830
we could perhaps set the
weight here to be 100.

112
00:06:11,830 --> 00:06:15,160
And on the neighborship
towards router 3,

113
00:06:15,160 --> 00:06:18,280
we could set the weight to 200.

114
00:06:18,280 --> 00:06:23,140
What this is going to cause is
any traffic on router 1 going

115
00:06:23,140 --> 00:06:28,010
to AS 200, any prefix
learned from as 200,

116
00:06:28,010 --> 00:06:33,400
it would choose the top
path here to get to AS 200.

117
00:06:33,400 --> 00:06:37,060
Now, router 2 would be a
little more interesting.

118
00:06:37,060 --> 00:06:42,208
Router 2 by default would choose
to follow the external path.

119
00:06:42,208 --> 00:06:43,750
And that's what
we're saying we don't

120
00:06:43,750 --> 00:06:46,810
want it to do because
that's only a 1 gig link.

121
00:06:46,810 --> 00:06:50,980
So instead, what we do is on
the neighborship to router 4,

122
00:06:50,980 --> 00:06:53,380
we set the weight to 100.

123
00:06:53,380 --> 00:06:55,420
And on the neighborship
to router 1,

124
00:06:55,420 --> 00:06:58,180
we set the weight to 200.

125
00:06:58,180 --> 00:07:00,310
Remember, highest weight wins.

126
00:07:00,310 --> 00:07:02,980
And what ends up
happening, router 2

127
00:07:02,980 --> 00:07:08,350
will now choose this path to
router 1 when going to AS 200.

128
00:07:08,350 --> 00:07:10,900
And we've accomplished our goal.

129
00:07:10,900 --> 00:07:13,390
This was, of course,
a very simple example

130
00:07:13,390 --> 00:07:18,050
where we were using a primary
versus a backup circuit.

131
00:07:18,050 --> 00:07:21,100
And because of that, we weren't
trying to do it per prefix.

132
00:07:21,100 --> 00:07:24,220
We just could do it
per neighborship.

133
00:07:24,220 --> 00:07:27,490
But since the routers have
to be configured separately,

134
00:07:27,490 --> 00:07:30,610
this is why we said it doesn't
make for a very good domain

135
00:07:30,610 --> 00:07:34,150
wide policy because
each device has

136
00:07:34,150 --> 00:07:37,800
to be configured individually.

137
00:07:37,800 --> 00:07:40,740
In this video, we
took a closer look

138
00:07:40,740 --> 00:07:44,760
at Cisco's BGP wait
feature that we

139
00:07:44,760 --> 00:07:48,390
can use right at the top of
our route selection criteria

140
00:07:48,390 --> 00:07:53,280
to influence the path selection
made on an individual router.

141
00:07:53,280 --> 00:07:55,950
Again, the downside
to this feature

142
00:07:55,950 --> 00:07:59,160
is it's not passed
in BGP updates.

143
00:07:59,160 --> 00:08:02,280
Therefore, it only
affects the local device.

144
00:08:02,280 --> 00:08:05,830
Meaning to really
influence path selection,

145
00:08:05,830 --> 00:08:09,690
we have to configure all of
the devices individually,

146
00:08:09,690 --> 00:08:13,750
which certainly isn't ideal
in a large environment.

147
00:08:13,750 --> 00:08:15,960
I hope this has been
informative for you,

148
00:08:15,960 --> 00:08:19,070
and I'd like to thank
you for viewing.

149
00:08:19,070 --> 00:08:22,000