[AUDIO LOGO]
So now that we've seen how weight operates,
let's take a look at local preference.
Now, we're going to see as we go through this video
that local preference in a way is quite similar to weight.
We're going to use it to affect our outbound routing decisions.
Now, of course, where it's very different
is that this is a BGP attribute and therefore
gets passed in BGP updates.
So let's jump in and take a look at some of its details.
And then of course, we'll bring up a diagram at the end
and get an idea of how we can use this to influence our BGP
path selection.
Local preference is actually referenced in BGP rule number
two, where we're going to prefer the path with the highest
local preference.
So once again, this is a value where the highest wins, just
like weight.
And just like weight, this is also
used to set the preferred outbound eBGP path.
Now, just like we mentioned briefly in our discussion
during weight, this can also be used in conjunction
with communities and possibly used
to influence the return path.
But generally speaking, again, this
is going to be for outbound path selection.
And one of the primary reasons that it's for outbound
is that this is only going to be propagated within the AS, which
means it's only going to be sent to iBGP peers and confederation
peers since those would be part of the same AS as well.
Now, some of the advantages of using
local preference over weight--
well, the first here is this of course
allows for a consistent domain routing policy.
The reason is that this value is passed through the BGP updates
within the domain.
Now, we don't generally want to use weight and local preference
together.
Normally, we're going to choose one to use.
So we really want to avoid using weight here.
But again, keep in mind that if you do have one router that you
needed to make a different decision,
weight can still override local preference.
It's just generally not recommended
unless you have a very specific reason to do so.
For the same reason, we sort of want
to avoid changing the local preference inside the domain.
Now, the main reason for this one
is to get that consistent routing policy
we were just talking about.
It's not going to be consistent if we change
things inside the domain.
Now, the implication here, in case you didn't pick up on it,
is that means that when we get updates from our neighbors--
so from eBGP from other AS numbers--
if we want to select a specific exit for those routes,
we would want to set the local preference as those routes are
coming in to the AS.
Also, if we need to set a preference on routes that
are being redistributed, we should do that
at the point of redistribution.
So essentially, what we're saying here
is we want to set the local preference on the BGP update
when it's introduced to our BGP domain,
either internally through redistribution or maybe
the network statement or when we bring the routes
in from an outside AS.
Now, this is a well-known and discretionary attribute--
well-known meaning that everybody who supports BGP
will support local preference.
Discretionary means you don't have
to set it if you don't want to use this feature.
Now, if we don't set it, we'll talk about what happens.
Also, as a note here, this is a 32-bit value.
So it's quite a bit larger than weight, which remember,
was 16 bit.
But honestly, we don't really need all those values anyway.
It just happens to be a 32-bit number.
So what are the default behaviors for local preference?
Well, the default value on Cisco equipment is 100.
Now, you can change the default local preference
by using the bgp default local-preference command.
And that will change the 100 to, of course, whatever
you decide to set it to.
But if you leave it alone, it will default to 100.
Now, as far as default behaviors based on prefixes,
let's talk about each of these a little bit differently.
So first, we have incoming prefixes.
And this is simply going to refer to prefixes
being learned on this router.
And there's three choices here.
Choice number one is it will apply the default.
And again, it's talking about this default
up here when we reference default at the bottom.
So in this case, it would be 100, unless we change that.
But this is what's going to be applied
to the external prefixes as they come in from eBGP,
because remember, eBGP updates would not
have a local preference on them.
They don't carry local preference.
Option number two, we can selectively set these values
with a route map or routing policy language,
depending of course on our platform.
But we can of course override the default
on any prefixes we want to.
The third choice here, of course,
is if it's coming from iBGP, meaning it's already
internal inside of my BGP domain, well,
I'll simply accept the local preference
that's already on it.
There would be no need to change it.
However, if you do need to change it,
you certainly can using the route map or RPL,
because notice this is saying that it's
going to accept it only if there is no route map or RPL
on the update.
So assuming there is not one, then we accept the value.
Now, for prefixes that we're sending--
so outgoing prefixes-- the only way this is going to be set
is with that route map or RPL.
That's the only choice.
Otherwise, there is no just default behavior.
Now, for routes that we are redistributing into BGP
on the local device, well, once again, the default
is going to be applied, assuming that you do nothing else.
Or once again, we can selectively set it
with the route map or RPL.
So those are our choices based on which direction
the prefix is going.
So now let's take a look at how this would work in a scenario.
So here we have a very similar scenario
that we used during weight where we have two AS
numbers connected by two links.
One is a 10 gig, and one is a 1 gig.
And our goal here is going to be to prefer
the 10-gig link for our traffic going to AS 200.
Well, the nice thing about local preference
is all we have to do to get this to work is on router one,
for the prefixes learned from router three,
we simply set the local preference
to be 200 on those paths.
That 200 is then going to be passed down to router two.
Router two is also going to learn a local preference of 200
for the prefixes going towards router one
where it would have the default local preference of 100 going
towards router four.
So even though, by normal BGP rules,
router two should prefer the external route going to router
four, now it's not going to.
It's going to go with the highest local preference.
And once again, traffic would then flow from router two
to router one and from router one to router three,
getting into AS 200.
Therefore, we've selected our exit from AS 100.
And of course, the nice thing about this,
as opposed to weight, we only had
to configure one router here.
We configured router one.
We set that local preference to 200.
And that's the only place we had to do any modifications
to influence this path.
So in this video, we saw how to use local preference,
much like we saw how to use weight to influence
the traffic leaving an AS.
Now, again, with things like community,
it could be used to affect the return path,
but we'll talk about that later.
The main thing to take away from this
is local preference does sort of have
two advantages over weight.
The first is that it's industry standard.
It's part of BGP and, therefore, is sent to neighbors.
And while that brings us to number two, which
is directly related to number one,
that means that we can use it to build
a consistent routing policy for our whole AS or domain.
And we don't have to go configure every single device
individually like we did with weight.
I hope this has been informative for you,
and I'd like to thank you for viewing.