[AUDIO LOGO]
So now that we've seen weight in action, now let's jump in
and take a look at local preference.
In a lot of ways, these are a bit similar,
meaning that highest wins.
They're going to affect our outbound routing decisions.
And we're going to set them in a very similar fashion.
But the main difference, of course,
is that weight only affects the local router, where
local preference will affect the entire AS.
So as we jump in to look at our example,
we're going to be affecting an entire AS's decision
to get to a destination and, at the same time,
only configure one router.
So let's jump into our topology, take a look
at what our game plan is going to be,
and then we'll jump into the command line
and make it happen.
So for this demonstration, we're going
to be looking at a route that's actually coming from router
8 being sent over to router 7.
And as it is right now, AS 100 over here
should currently be exiting through router 1,
except router 3, which should be going to router 7 directly.
That decision we're going to be keeping.
But what we want to do with our local preference
is we want to change this so all of the routers,
including router 1, switch over and start going to router 3.
We're going to be doing this by simply changing
the policy on router 3 itself.
Something else to keep in mind as we're jumping in
and begin looking at all of this, router 1 and router 2
are both configured as route reflectors
in a redundant cluster.
So just keep this in mind, as we jump into the command line,
we will see some evidence of this
when we see how the updates are being propagated
as well as we'll see things such as the cluster list in our BGP
updates.
So just again, keep this in mind as we
jump into the command line and begin
to implement our game plan.
So let's go ahead and do just that.
So let's just start on router 1 with doing a show
bgp for the 100.8.8.0 prefix.
We see that we're receiving multiple paths.
However, we can see that we're currently
following the path from router 7 going external to our AS.
Let's take a look at what router 2 is doing.
Now, router 2, we can see here, has a rather interesting
problem.
Yes, it's currently using the best path going to router 1,
but that's not even the issue.
It's receiving the update from router 3.
However, it still has a next hop of 10.7.7.7, which is currently
inaccessible.
Keep in mind that no matter what we
do with policy, if the next hop is inaccessible,
there's no way router 2 is ever going
to use this particular path.
So we're going to have to fix this first.
But before we do, let's still hop over
to router 4 and see what its current path selection is.
So on router 4, looking at the same prefix,
we see that it has learned this information from both route
reflectors, both with the next hop of router 1, the 10.1.1.1.
So aside from router 3 itself, nobody else in AS 100
is using router 3 as the exit.
But before we can make it do so, we
have to fix that next hop issue on router 3.
So what we need to do is go into router bgp 100,
go into neighbor 10.1.1.1 for the address family
ipv4 unicast.
And we'll simply say next-hop-self.
We'll do the same thing for router 2.
Commit the changes.
And exit configuration.
Now let's go over and verify that router 2
has the prefix correctly now.
So on router 2, we'll simply repeat the last command there.
And we can see that now, even though we're not using it
at the moment, it's at least receiving the update
from router 3 with a next hop of router 3.
And it's no longer listed as inaccessible.
So now, as long as we change our policy
to make this the best route, using,
of course, local preference, now it
can actually choose it and use it
because it's no longer inaccessible.
So let's go ahead and do just that.
Again, this policy is going to be done on router 3.
So the first thing we'll do is create a prefix set.
We don't necessarily need this.
We could do it on all routes.
But we'll pick on just the one we're supposed to be doing.
We'll call this PS_FROM_R7.
And it's going to match on the 100.8.8.0/24.
We'll end the set.
Then we'll create a route policy.
We'll also just call this FROM R7.
And we'll set our policy.
We'll say, if destination is in our prefix set,
then what we're going to do is set the local-preference.
Now, remember, this is the path that we want to use.
Highest local preference wins, and the default
local preference is 100.
So what we need to do here is set this literally to any value
higher than 100--
so 101, 150.
We're just going to do 200.
It's just a quick, easy number.
But really, any number higher than the default.
If we were trying to get it not to use this path,
then we'd go the other way.
We would set the local preference somewhere below 100.
So realistically, we could have implemented
our overall policy on router 1 instead
and lowered the local preference.
But we did say during our game plan that we
were going to do this on router 3-- so in which case,
we'll set this to a local preference of 200.
So we'll set the 200.
Then tell it to pass the routes through, and else pass,
because again, we're not trying to use this as a filter.
We'll end our if statement.
We'll end our policy.
We're go into BGP for router 7, of course,
in our address-family.
And we're going to say, route-policy RP_FROM_R7.
And of course, this would be inbound.
Now, before we commit this change,
I just want to show you something very interesting
that IOS XR does for us.
Let's get a Wireshark capture going
of the interface between router 3 and router 7,
looking at BGP traffic.
Specifically, we're going to be looking for route refresh
messages.
Let's get that Wireshark capture set up.
So here we have our capture running
with our specific filter to allow for BGP
unless the length is 19.
Once again, this should keep out the keep-alives.
So this is going to capture just other BGP traffic.
Now let's go commit our change.
So we'll commit our change.
Exit configuration.
And let's go back and look at Wireshark.
Notice that as soon as we applied that configuration
change or policy change on IOS XR,
it automatically does that route refresh for us.
If you remember, when we were talking about route refresh,
we mentioned that this is a manual process
that you have to trigger it.
And on IOS XE, that's definitely true.
On IOS XR, it will usually detect
that you've applied a policy change
and therefore do a route refresh.
If not, you can always, of course,
do it manually if your changes don't take effect.
But now that we saw that it actually did a route refresh,
let's go ahead back over to the command line
then and see if our local preference
changes have taken effect.
So let's go back to our other routers and check it out.
Router 1, let's go ahead and look at our show bgp again.
And we see right here that the path learned
from router 3 going through router 3 now
has a local preference of 200.
And it's selected as best.
Let's check router 2.
On router 2, we see the same thing.
It's learned from router 3 with the next hop of router 3.
It has the local preference of 200.
And it's selected as best.
Finally, let's check router 4.
So as we see here on router 4, like previously, it
learned a copy of this path from both route reflectors,
both going to router 3 as the next hop.
And in this case, the one from router 10.1.1.1
was selected as best.
But they both have a local preference of 200.
So we can see that local preference is working exactly
as we designed.
In this video, we used local preference on a single router
to influence the BGP path selection for the entire AS.
And that really is the big advantage of local preference
over something like weight.
Remember, weight is first Cisco proprietary.
But more importantly, it only affects the local router, which
means if I wanted to make this same change using weight,
I would have had to have gone to all four routers
and made that change.
In this case, I made one change on router 3,
not counting changing the next hop,
but one change to our policy on router 3
to set that local preference to 200, higher than the default,
to get us to prefer that path.
I hope this has been informative for you,
and I'd like to thank you for viewing.