So in this video, let's start off
by looking at the BGP path selection criteria as a whole.
So we're going to go through all of the different steps.
Now some of the steps are, of course,
going to be broken down in future videos,
the ones that require a little bit more discussion, and/or you
could say the ones that we use more commonly
for path selection.
Some of the other ones, we will cover in full
here in this video.
But there are some of the rules that
sound relatively straightforward that
do have some caveats with them.
So we're going to make sure we cover those either here
or in the future videos, when we cover
those topics individually.
And we will make sure you understand which ones are which
as we go through.
And I'll mention whether this is going to be in a future video
or if this is the most that we're going to be covering it.
So let's jump in and look at the path selection criteria,
looking at, well, some of the details,
and saving some for future videos.
Our first step is that we're going
to prefer the path with the highest weight.
Now weight is actually a Cisco proprietary attribute.
And as such, it does not get sent in BGP updates.
Note, as we go down through the path selection criteria, some
of these rules, such as rule one here, will be listed in blue.
Some of them will be in yellow.
The blue indicates that there's a more detailed video
on how this works coming up later in this skill.
If the rule is yellow, it means we're
going to have the full discussion on it
here in this video, because it's a fairly simple rule,
and maybe it just has a few little caveats.
So keep that in mind as we go down here.
We're not going to be talking a lot about weight right now.
Because again, there's a separate video coming up next.
Sort of along the same lines is rule number two.
This is the highest local preference.
This one is not Cisco proprietary.
It is part of the BGP standard, and therefore
is carried in BGP attributes.
Once again, the highest wins.
Number three is our first rule, that's rather straightforward.
And it simply says that we are going
to prefer the path that was locally originated
via either the network or the aggregate BGP subcommands,
or through redistribution from an IGP.
Now this is fairly straightforward.
It's just saying that locally originated is preferred.
However, note the caveat, adding a little more detail here,
that local paths coming from either network
or redistribution are preferred over something
coming from the aggregate address command.
So even within the locally originated,
there's still a hierarchy where, again,
network or redistribution beats out an aggregate address.
Our next rule is simply to prefer the path
with the shortest AS path.
When we say shortest, we're talking
about the number of AS's, not the actual length.
So for example, if I had a path 65001 versus the path 123,
the winner here is going to be the 65001.
Because even though the bottom path might only be three
numbers, it's three separate AS's.
So again, it's the number of AS's in the path.
Next is another fairly straightforward rule.
We prefer the path with the lowest origin type.
So the lowest here is an I, which means IGP.
In the case of a Cisco device, this generally
means that the route was brought in with the network statement.
Next would be E, meaning EGP.
This is generally not going to be set anymore
unless an administrator actually set the origin code
purposefully to E. And then finally is the question mark.
This simply means unknown origin.
On Cisco devices, this generally means
that this path was originated through redistribution.
So all we really have to remember
is that I is going to beat E, and E
is going to be question mark.
Now again another quick note here--
origin code is not very commonly used
to manipulate path selection, which
is why we're not discussing it in great detail here.
However, this is still a part of the path selection criteria,
and we can set this through route maps and route policy
language.
So keep in mind, although not common,
we can certainly use the origin code to manipulate BGP path
selection if we wanted to.
Next up is to prefer the path with the lowest multi exit
discriminator, or MED.
Cisco generally refers to this as the metric
when you're configuring it.
And in show and debug commands, there
are a few exceptions where they refer to it as the MED,
such as when you're setting it in RPL on iOS XR.
But generally, speaking when you see metric,
they're referring to the MED.
And again, this is something that we have
another video on coming up.
So we're not going to spend a lot of detail on it right now.
Next up is fairly simply to prefer external paths, or EBGP
paths, over internal paths, or IBGP paths.
Now once again, a few little caveats.
First, if best path is selected, we're
going to continue on to step nine,
or multipathing, which we're going to be
talking about in just a moment.
Also note that if these paths contain confed attributes,
they are considered local to the confederation.
And for the sake of this path selection criteria,
they will be treated as internal paths.
There's no distinction between confederation
external and confederation internal.
Next is to prefer the path with the lowest IGP metric
to the next hop, which is essentially just saying
if this traffic is leaving the network anyway,
then let's get it to the next hop through the closest IGP
exit.
And here we will continue, even if best path is already
selected.
Then we have step nine, which is our multiple paths,
or our multi path rule.
Now keep in mind, BGP will select one best path.
That's what it's going to advertise to its neighbors
and things like that.
That doesn't mean that it can only put
one route in the routing table.
We can enable BGP for multipathing,
and that's what rule 9 here is all about.
The default on most Cisco platforms
is to install one route from BGP into the routing table.
But if you change the max paths to something like four, six,
eight, something like that, then it's
going to hit rule nine here and choose, essentially,
which routes are a tie down to this point,
and put all of those up to the max value
into the routing table.
And this is precisely why rules seven and eight
said to continue, even if best path was selected.
Because we had to still see if they were ties
that could be put into the routing table.
Now at this point, we're going to continue only if best
path is not yet selected.
So if it gets down to step nine here and we still have a tie,
then we are going to still keep going.
Because again, even though we might
be putting all of those prefixes into the routing table,
they can't be chosen as the best path.
Because we only advertise one path to our neighbors.
Next is rule 10, which simply says if both of the paths
are external, then it's simply going
to go with the one that was received first.
The idea, of course, being that it's proven
itself to be the most stable.
The idea here is, it minimizes route flaps so that a newer
path doesn't displace the older one all the time, even
if the newer path would be the preferred route based
on the next lesson criteria, such as 11, 12, and 13.
Now this step won't always come into play.
So we're going to skip this step in certain criteria.
The first is if you have actually enabled BGP
best path compare router ID.
The reason for this is, of course, we
haven't seen router ID yet.
That's one of these steps, 11, 12 or 13.
It's a mystery.
We'll find out.
But we haven't gotten to router ID yet.
So if we're telling it it has to compare router ID,
then clearly, we're not going to stop here at step 10.
It will also skip it if the paths are
from the same neighboring router ID,
or if there's no current best path.
It's not going to use this as the criteria
to choose the best path.
And it's also not going to look at this if the neighbor that
was offering this goes down.
It'll continue on with other steps.
The next step is step 11.
And as you can see, the mystery is solved now,
because this is coming from the lowest router ID.
The router ID, by default, by the way,
is going to be the highest IP address on the router,
with preference given to loopback interfaces.
Or more preferably, you as the administrator
can use the BGP router ID command
and manually set the router ID.
Now a quick note on the router ID here--
if you are doing BGP synchronization,
which is not commonly done anymore,
but if you are, and your underlying IGP is OSPF,
there is an RFC that states that the BGP router ID and the OSPF
router ID must match in order to do synchronization.
So keep that in mind in your design
if you are doing BGP and OSPF with synchronization, which,
again, not commonly done.
But just keep that in mind with your router ID design.
The fact of the matter is, you probably
want to make them the same anyway,
just because why have more than one address
to remember a router by in two different protocols?
So unless you had some outstanding reason to do so,
we would probably make these numbers the same anyway.
But just keep it in mind, that in that synchronization
scenario, they actually do have to match.
And one caveat on this rule, that if there's a route
reflector, the originator ID is used instead of the router ID.
So keep that caveat in mind when we're
dealing with route reflectors.
So we just had a caveat related to route reflectors.
Now we have a whole rule for route reflectors.
You can see right here, our first note,
that this is only present in BGP route reflector environments.
Well, what are we talking about?
Well, it's quite simple.
If that originator ID is the same for multiple paths--
which, again, that's what this whole path selection criteria
is for--
we're going to go with the minimum cluster list length.
Just like the AS path length, it's the number of clusters
that this particular path goes through.
So we're going to prefer to go through the lower
number of route reflectors.
So because of this rule, we can, in fact,
peer with route reflectors or clients in other clusters
without creating an issue.
However, be aware that in order for this to work,
the receiving router has to be aware of those route reflector
specific BGP attributes.
I can't imagine that any devices today would not
be aware of that.
However, maybe there's something out there that's not.
Just be aware that this rule would not
take effect in that case.
Finally, we prefer the path that comes from the lowest neighbor
address.
This is going to be using the IP address that's
used for the BGP neighborship.
So this might be the directly connected physical interface.
It may be a loopback interface.
It's whatever address is used in the neighborship.
Again, it's going to correspond with the remote peer
in that TCP connection.
So as you can see, this is flat out down to a tiebreaker.
There's no way we're going to come out of Rule 13
with two best paths.
There will only be one.
So in this video, we went through the BGP best path
selection criteria.
So when BGP has multiple paths to get to a single destination,
it will go down this list, one by one,
all 13 steps, if needed, till it comes down to one best path.
Now we also saw that at rule nine, if we're
putting multiple routes into the routing table,
it can, of course, support multipathing.
But it will still continue until it
has one best path, because that's what it
has to send to its neighbors.
So we'll go down the list until there's
a single path, eliminating all the other paths as we go.
I hope this has been informative for you,
and I'd like to thank you for viewing.