- [Narrator] When BGP makes its path selection decision
it can be a lot more involved than OSPF or ERGIP.
OSPF can simply say,
hey let's look at the bandwidth
and calculate the cost based on the bandwidth.
We determine the shortest path to the destination
network using the Daxter algorithm,
and we go with the lowest cost path.
ERGIP by default only considers bandwidth and delay.
However, BGP can take several different things
into consideration, and I've got all of them
listed for you here on screen.
This is a comprehensive listing,
and its more than you might see in some documentation
because some of this deals with more advanced configuration.
Such as route reflectors or setting up multi-path BGP.
But I wanted to show it to ya so you could have a
comprehensive listing, and then later in this video
I'll point out the most important path selection parameters
that you and I might deal with on a day to day basis
as we might try to influence BGP to pick a specific
inbound route or an outbound route.
But let's go through the comprehensive listing first
just so we can be exposed to that.
The path selection parameters are listed
top to bottom here on screen
in order of preference, and the first one
that we see is weight.
This is a Cisco specific parameter and its locally
significant to a router.
In other words, it doesn't get communicated
to our neighbors.
As a route comes in to our router from a neighbor
we can stamp it with a weight.
We can say that routes coming in from one router
or one neighbor have this weight,
and routes coming in from this other neighbor
have a different weight.
And a higher weight is preferred.
That's a really common way to influence our outbound
of path selection decisions.
And if we have more than one path to get
to a destination network, we can go with the
routes that have the higher weight and came
from a specific neighbor.
Another parameter that's commonly used for outbound
path selection decisions, is local preference.
Now this is not Cisco specific.
With local preference, a higher value is preferred,
but this value is not locally significant to a router.
It gets communicated with all other routers within
an autonomous system.
And next we're asking, from where did this network
prefix originate?
We're going to prefer a route that was originally
advertised using the network statement or a route
that was redistributed into BGP.
Those route origins are going to be preferred
as opposed to a route that was injected into BGP
using the aggregate hyphen address command.
Next up is the AS path length.
This is the number of autonomous systems that are in
the autonomous system path or the AS path attribute.
That shows the listing of autonomous systems that we
need to travel through or into in order
to reach a certain network prefix.
Let's says that our BGP depology table
tells us that we've got two different ways
of getting to a specific network prefix.
Well, BGP can prefer the path that has the fewest
autonomous systems listed in the AS path attribute.
Next is origin time.
Was the route learned by BGP from an IGP?
In other words, an interior gateway protocol
like OSPF?
Or was it learned from an EGP, an exterior
gateway protocol ,like BGP.
Or do we have incomplete information.
The origin type of I for IGP,
that's preferred over an E for EGP,
and that's preferred over the question mark
for incomplete information.
Up next we have the MED.
The multi-exit discriminator.
This is commonly used to influence inbound route selection.
Such as when we're trying to influence routers
out on the internet to use a specific ISP
where they're coming into our network.
We apply this parameter to the routers in one autonomous
system to influence decisions in a different
autonomous system.
Here, the lower MED is preferred, and if
everything is still a tie,
we look to the paths attribute.
Where an EBGB path, that's a path between autonomous
systems, is preferred over an IBGB path,
that's a path within an autonomous system.
The next tie breaker is the next top IGP metric.
Where we look at the next top address and ask,
what is the lowest IGP metric?
Maybe we're running OSPF as our internal gateway protocol.
If the different paths that we have to select from
have different OSPF metrics to get to the next
top address, then we can go with the path
with he lowest OSPF metric.
Then we ask if we're enabled for BGP multi path.
Do we need to have multiple paths injected
into the routing table?
If we still haven't selected a best path,
the search continues, and the next tie breaker is the
age of the EBGP route.
Which one is the oldest?
And the oldest one, that's the one that's preferred.
It's older and wiser we assume.
If we still have a tie, we're going to go with the
lowest router ID.
Specifically, we're asking, which neighbor has the lowest
router ID?
The next parameter deals with route reflector
BGP configuration.
If we do have that type of configuration, we can
prefer the route with the minimum cluster list length.
Now that's not something we need to be concerned
about here at the CCNP level.
We'll leave that for your CCIE studies.
And the final tie breaker is to answer the question,
which of my neighbors has the lowest IP address?
The neighbor with the lowest IP address
will be the preferred next hop.
In other words, the preferred path.
And if you count all of these up,
there are 13 criteria that we could examine.
That's a lot to remember, and I've heard
a variety of memory aids to help you
memorize a specific set of path selection parameters.
But in this video, I wanted to share
what I consider to be the simplest memory aid
that I've run across.
Also its my favorite,
and it does a great job of helping us remember
some of the key components in this BGP path
selection decision.
Its not totally comprehensive.
It doesn't get into route reflective considerations,
but it does help us memorize the BGP path selection
parameters that are used, the vast majority of the time.
And by the way, I didn't make up this memory aid,
its just one of the more popular BGP memory aids
out there, and I wanted to share it with you.
Its an acrostic, and it goes like this:
We love oranges, as oranges mean pure refreshment.
I'll say that one again.
We love oranges, as oranges mean pure refreshment.
Here's what that acrostic means.
The W in "we" reminds us of the W in "weight".
We love, the L in "love" reminds us of the L in
local preference.
We love oranges. The O in "oranges"
reminds us of the O in originate.
We love oranges, as.
The A S in "as" reminds us of the AS path length.
We love oranges, as oranges.
The O in the second instance of the word oranges,
reminds us of the O in origin time.
We love oranges, as oranges mean.
Here the M in mean reminds us of the M in the
multi-exit discriminator, the MED.
We love oranges, as oranges mean pure.
The P in "pure" reminds us of the P in "paths".
And finally, we love oranges,
as oranges mean pure refreshment.
With the R we jump down to the router ID.
And this might be a simpler table
for you to work with and memorize.
We love oranges as oranges mean pure refreshment.
This is still a sizeable list though.
So the question is, what do we as network engineers
in the real world need to do typically, to influence
path selection for our enterprise routers
going out to the internet, and how do we influence
internet routers as they come in to our enterprise network?
It really boils down to 4 parameters that we typically
use to modify on our router.
After all, we probably don't have the luxury of
configuring the ISP's routers.
We have to keep the configuration local to our router.
And here are the 4 most common path attributes
that we'll typically use.
They are: weight, local preference,
autonomous system path length, and the MED.
And that's a look at how BGP makes its path
selection decision.