Up until this point, we haven't talked much about BGP's best
path algorithm.
What are the processes that it goes through when determining
what is the best path?
We have demo'd a little bit of it, though.
If you followed along in the Nugget on Route Maps,
you saw where we set the weight on a path coming in,
in order to manipulate how that traffic actually worked.
And that's what we're going to talk about in this Nugget,
is actually about weight.
But before we jump into weight, let
me set up this scenario about how BGP is
doing-- what it's really doing. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
doing-- what it's really doing.
Think about this scenario for a second.
We are a service provider.
We have a bunch of clients.
We've got a router here.
What happens when we start peering with other service
providers?
Maybe we've got a service provider here--
we'll call the service provider A, service provider B--
over here, we'll say we've got service provider C.
And all of these service providers
start advertising routes into us.
Then we take it a step further and we
start advertising those routes through iBGP, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
start advertising those routes through iBGP,
or maybe we advertise it outbound through eBGP.
You could even look at it as-- a route comes in from service
provider A. We're going to advertise it back out to B,C,
and so on.
How does BGP then determine if this route
came in from all of these different service providers?
How does it know which one is best?
Well, at the fundamental level, BGP
just has a list of attributes that it goes down,
one at a time.
So for now, I'll just call this attribute A, attribute B,
attribute C--
so when service provider A advertises an NLRI to us, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
so when service provider A advertises an NLRI to us,
it not only has that prefix, but it also has the attributes.
Recall, that's what makes it an NLRI--
the Network Layer Reachability Index.
Service provider B advertises in an NLRI for the same prefix,
but it may have different attributes.
And BGP is going to go down the list, comparing
one attribute at a time.
And when it finds a difference in those attributes,
that's when it determines which attribute is best.
So what this skill is really talking about is, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So what this skill is really talking about is,
which attributes does it look at,
and then how does it determine if one of those attributes
is better than the other?
So let's clear the screen and start
by talking about our first attribute in the BGP selection
process, and that's weight.
Weight is a big one.
Weight is an important one.
So here we have our router once more.
We'll put service provider A back on the map,
advertising a route in, service provider B back on the map,
advertising a route in--
here's where weight comes into play. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
here's where weight comes into play.
Weight can only be set directly on the router
that it comes in on.
We do not advertise weight to any other routers.
So if I'm advertising out through eBGP
over to a different service provider here,
or if I'm advertising to an iBGP within my autonomous system,
weight will never be sent with my NLRI advertisements that
are going outbound.
Where weight comes into play is if we
want R1 to explicitly determine that the advertisement that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
want R1 to explicitly determine that the advertisement that
came in is the best and that's where we should always
prefer traffic.
For instance, service provider A sends in a prefix--
make something up-- for 100.0.0.0/8,
service provider B sends in a prefix, 100.0.0.0/8,
and everything about these advertisements otherwise will
be identical.
For whatever reason, let's say we've created a policy that
says, for traffic destined to 100.0.0/8,
always use service provider B. When service provider WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
always use service provider B. When service provider
B's advertisement comes in, we'll create a route map that
sets the weight on this router for that prefix.
The higher the weight, the more preference
it gains, and by default, prefixes that come in
have a weight of 0, so all we have to do
is set it to any number greater than 0,
and by default, that prefix will win.
The best example of this was in our virtual lab.
Let's draw up a perfect scenario as to why
we would implement weight.
In our virtual lab we had R2 and R3 as part of AS100. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
In our virtual lab we had R2 and R3 as part of AS100.
So if I draw the little dotted line here,
we'll say this is AS100, then at the top of this topology
we had R4.
When R2 and R3 advertised routes upwards towards R4,
it had to choose which path it liked best.
And later down the line, we'll talk about how it got to this
point that R4 was choosing R2 as the best path when it actually
wasn't.
You see, this link was using fast ethernet,
whereas this link over here was using gigabit ethernet. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
whereas this link over here was using gigabit ethernet.
So a perfect reason why we may want to implement a weight
would be right here on R4, setting the weight of routes
coming in from R3 to 100, or really any digit that's
greater than 0.
That way, R4 will put a preference of traffic
going outbound towards R3 when it's destined for AS100.
Let's fire up the virtual lab and get this in action.
With the virtual lab fired up here,
I'm going to jump over to R4 and quickly give it
a show bgp ipv4 uni, just to get a lay of the land, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
a show bgp ipv4 uni, just to get a lay of the land,
and you can see exactly what we were talking about here.
We've learned all of these 1.1.1.1 routes,
and we're preferring the routes towards R2 right now.
But this is using a less than optimal path,
because if I give it a show ip int brief,
we can see our link towards R2 is using
fast ethernet, whereas our link towards R3
is using gigabit ethernet.
So let's fix this with a route map.
I'll start by creating a prefix list that grabs
all of those 1.1.1 routes. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
all of those 1.1.1 routes.
I'll call the prefix list Filter1,
I'll say permit 1.1.1.0/24, so it grabs any 1.1.1 address.
And I'll say ge 32, because it's going to be a 32-bit mask.
Now I'm going to create a route map that's
going to be for our neighbor relationship with R3.
So I'll call this r3weight, I'll specify a permit statement
sequence number 10, then I'll match on the prefix lists.
So I'll say match ip address prefix list Filter1. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I'll say match ip address prefix list Filter1.
There we go.
Now I'm going to set a path attribute
as it's coming inbound.
I have a question mark here right after set.
There's actually a lot of things that we're
about to talk about coming up.
Here's weight, but we can also thing see things like metric,
local-preference, community, as-path, origin--
quite honestly, almost all of the things
that are used in the BGP best path algorithm
can be manipulated in a route map. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
can be manipulated in a route map.
For now, let's stick to weight.
I'll specify weight, set the weight to 100--
now for my route map, I want to just
have a permit statement that grabs everything else, so
that way we're not accidentally filtering out
any routes with an implicit deny at the end of the route map.
This route map is called R3weight,
I'll specify permit sequence number 20,
press enter, and now I can exit out of route map configuration
mode.
I'll jump into BGP configuration mode,
and I'll adjust my neighbor relationship with R3--
100.100.34.3 and specify let's use a route-map of R3weight WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
100.100.34.3 and specify let's use a route-map of R3weight
for routes coming inbound.
We do have to specify the direction there.
I can press End.
We can quickly make our policies and routes refresh
by doing a soft reset.
So I say, clear bgp ipv4 uni, specify the router's IP
address.
Then the direction will be inbound.
I'll press Enter.
Now lastly, I'll give it a show bgp ipv4 uni,
and we'll check out the routes.
Now I see all of my 1.1.1 addresses WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now I see all of my 1.1.1 addresses
are preferring router 3 because they have a weight set to 100.
So when all else fails, you can set a weight
on routes coming inbound to tell that local router,
prefer the route coming from this specific provider
or partner or neighbor over any of the other advertisements.
So that's the first criteria that
goes into the BGP best path algorithm weight.
In the next Nugget, we're going to talk about local preference.
In the meantime, I hope this has been informative for you,
and I'd like to thank you for viewing.