Now, at this point, there are five attributes
remaining that BGP uses in its best path selection algorithm.
Here's the thing, though.
They're really just tiebreakers at this point.
They don't need a huge amount of explanation
because they simply exist when all else fails.
Let's jump on a whiteboard and draw up what those remaining
five attributes are.
The next and the ninth attribute that we're
going to be reviewing here is the lowest IGP metric.
In this case, we're pretending that R1 here maybe WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
In this case, we're pretending that R1 here maybe
is advertising its loopback address or something like that
of 1.1.1.1 down into this blue autonomous system.
If we're looking from the perspective R4 or R5,
it's going to learn about this path to R1
through two different channels.
An advertisement is going to come down
this way and then over to R4, and then an advertisement
is going to come down this way and then over to R5,
and then they're going to exchange paths back and forth.
So if R4 wants to get to R1, all of the other metrics
up to this point from its perspective WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
up to this point from its perspective
are going to be identical.
If we don't set a weight or a local preference,
if we're not using an AIGP, the AS path count
is going to be the same.
These are learning about these from internal BGP.
It's going to fall down to what is the lowest IGP metric.
In this case, it will probably have a lower cost going
this path to R2, and R5 will probably
have a lower cost going this path to R3--
now, unless there's a fast ethernet
link somewhere along the way that
could throw everything off.
But if we're assuming that all of these links WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But if we're assuming that all of these links
are gigabit ethernet or 10-gig ethernet, then
from R4's perspective, this path would be best.
In R5's perspective, this path would be best.
Going this path from R5 may be too long, and this path from R4
would be too long as well.
So that's the ninth metric, the lowest IGP metric.
The 10th metric is going to be the oldest EBGP learned route.
The reason that this exists is because routes are
coming and going all the time.
Routes are flapping all the time. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Routes are flapping all the time.
The oldest EBGP learned routes are probably
indicative of the most stable routes.
So that's why it picks the oldest EBGP learn route rather
than one that may be coming in and then going out, and then
coming in and going out, and so on.
The 11th tiebreaker here is the lowest neighboring router ID.
Recall that the router ID by default
is the highest address loopback, and if there are no loopbacks,
it's the highest address physical interface.
If I fire up the virtual lab for just a moment from R2's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If I fire up the virtual lab for just a moment from R2's
perspective, I can say show BGP IPV4 unicast neighbor because I
want to look at details on my neighbor
like, what is R1's router ID?
I'll specify my neighbor relationship here
going towards R1.
And we can see that R1's router ID is 1.1.1.4, the highest
address loopback.
It's, in fact, a best practice to manually set your router ID
so that in the event that you introduce new loopbacks, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
so that in the event that you introduce new loopbacks,
it doesn't create these flapping sessions or flapping routes,
because now we see that our router ID can actually be
used in the selection process.
So by simply creating a new router ID,
we could be throwing off some downstream selection
process that's happening.
Very quickly, we can go into Configuration Mode, router
BGP 100, and then we can specify our router ID with BGP router
ID and then specify something like to 2.2.2.3 or 4, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
ID and then specify something like to 2.2.2.3 or 4,
because I accidentally typed 4.
But you notice what happened the moment
we changed the router ID?
All of our connections went through a hard reset.
So keep that in mind that if you've built a neighbor
adjacency already and then you go to change a router ID,
it will tear down that adjacency and then rebuild it.
The 12th factor that's used in the BGP selection algorithm
is the minimum cluster list length.
The cluster list is an attribute that's set on a route reflector
as it's reflecting a route. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
as it's reflecting a route.
So as routes get reflected around an IBGP autonomous
system, if a route takes too many bounces,
BGP can look at all of the route reflectors
that it's passed through and choose the most efficient route
by choosing the minimum cluster list attribute that was set.
And lastly, the very last selection item
that's using the BGP selection process
is the lowest neighboring address.
So if all else fails and everything else is held equal,
BGP can look at the lowest IP address of our neighbors, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
BGP can look at the lowest IP address of our neighbors,
and that's the path that it will choose to go towards.
So that is the BGP best path selection algorithm steps
from 1 to 13.
I hope this has been informative for you,
and I'd like to thank you for viewing.