So weight was great and all for making a last minute judgment.
This router should prefer traffic
towards that destination.
But what happens when we start disseminating
that route through our own autonomous system using iBGP?
Remember, weight stayed on that router,
so if we were having to manipulate
each path with a route map that set the weight,
we would have to set that on every single router.
It may be preferable and efficient to be
able to set a metric that BGP prefers
throughout an autonomous system. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
throughout an autonomous system.
Let me draw it up for you.
Let's think one more time about this scenario
where we've got our R2 connection here
and our R3 connection here.
Both of these go up to R4.
The R2 connection is still using fast Ethernet.
The R3 connection is still using gigabit Ethernet.
And there are a couple other routers
in this topology within our autonomous system, R1 and R11.
It looks something like that.
What happens when R4 wants to advertise its loopback 4.4.4.4
down to each one of these devices? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
down to each one of these devices?
Ultimately, autonomous system 100
wants traffic destined to 4.4.4.4 to go out through R3.
So what R3 can do is set something
called the local preference.
This is what comes up second in the BGP best path
determination.
If none of these routers are setting a weight, all of them
will have a 0.
So it needs to go to the next criteria
to compare to determine what's best.
And in this case, local preference
can be set by a router, and that will WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
can be set by a router, and that will
be sent to all of the other BGP neighbors.
Now, local preference does get a little bit quirky.
For instance, when R4 advertises 4.4.4.4 down to R2 and R3,
by default, R2 and R3 set a local preference equal to 100,
then advertises that to all of its iBGP neighbors.
So if we want a path to be preferred within the topology,
say, through R3, we would need to tell
R3 to advertise a local preference greater than 100, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
R3 to advertise a local preference greater than 100,
maybe something like 200.
What's particularly interesting is when R3 advertises,
the NLRI with a local preference of 200,
R2 will then withdraw its advertisements for that prefix.
Again, all of this is accomplished with a route map.
So let's fire up the virtual lab,
build a route map that sets the local preference,
and then watch how AS 100 handles it.
So with the virtual lab launched here, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So with the virtual lab launched here,
I'm going to do a show ip interface brief on R4.
And we see we've got a loopback of 4.4.4.4.
It's not being advertised in BGP just yet.
So I'm going to say router--
nope, I'm not going to say router from privilege mode.
We're going to jump into configuration mode,
and then we're going to say router bgp 200.
Let's advertise that loopback, 4.4.4.4.
Mask 255.255.255.255.
Press Enter.
And back out.
Now we'll jump over to R1 in AS 100.
Let's just give it a show ipv4 unicast. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Let's just give it a show ipv4 unicast.
Take a look at the BGP table.
I see I've got 4.4.4.4 here, advertised from 100.100.24.4.
The local preference is 100.
In fact, all of these are 100.
And all of these were advertised by R2.
From R2's perspective, I'll say show bgp ipv4 unicast.
And we see the 4.4.4.4 address was
advertised from R3, as well as the EBGP relationship WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
advertised from R3, as well as the EBGP relationship
over on R4.
Now, at this point, you may be curious,
going like, wait a minute.
Local preference here is 100.
And there is no local preference for the route
that was advertised by EBGP.
Why then did it choose the route advertised from EBGP?
I mean, the selection criteria was weight.
And the weight here is 0 for both of these.
So then it goes to local preference, right?
And here we have a local preference of 100, and then
a local preference that's null.
Well, at the time that BGP is evaluating this criteria, when WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well, at the time that BGP is evaluating this criteria, when
it gets to local preference and it finds one that's empty
because it was an EBGP-learned route,
it default sets that to 100.
So at the time of evaluating local preference,
these are actually equal.
And it goes down the road and uses a different piece
of criteria to determine why this route was better
than this one.
Let's manipulate this, though, so that R3 advertises a higher
local preference.
And then R2 would prefer to send traffic over to R3, and then WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then R2 would prefer to send traffic over to R3, and then
up the gigabit Ethernet link.
From R3, we're going to go into configure terminal.
We're going to set a prefix list here.
We'll call this 4Route.
We'll say permit.
And then the 4.4.4.4/32 prefix.
Now I'll go into route-map.
I'll call this my R4route.
This will be again permit, and sequence number 10.
I'll match on ip address prefix list.
That was called 4Route.
And we're going to set the local preference equal to 200. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we're going to set the local preference equal to 200.
Jumping back into route-map real quick,
I'll make sure to give it another permit statement.
That way it catches everything else,
instead of an implicit deny.
Not end.
Then I'll go into bgp 100 configuration mode.
And I'll set my neighbor of R4 to have a route-map
of our R4route coming inbound.
Too many characters there.
There we go.
End.
I'll just give it a soft inbound reset.
We'll say inbound. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We'll say inbound.
That way it resets that connection to R4,
processes those inbound policies one more time.
And now when I jump over to R2, if I give it a show bgp
ipv4 unicast, look at this.
Now R2 prefers the route towards R3
because it has a local preference of 200.
Beyond that, if I jump back over to R1.
Hit the Up key there.
Run it one more time.
Look at this.
Right here, the advertised for 4.4.4.4 address
now is being sent to R3. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
now is being sent to R3.
That's because R2 is serving as a route reflector.
And R1 is the route reflector client.
So when R3 advertises a preferred route,
R2 installs that into its table since it's
withdrawn the request to all of the neighbors
that it advertised to, and then reflects the preferred route
to the route reflector clients.
So that's been how we can use local preference
to set a preferred route within an entire iBGP autonomous WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to set a preferred route within an entire iBGP autonomous
system.
I hope this has been informative for you.
And I'd like to thank you for viewing.