The next two BGP best path selection criteria
that we need to talk about are the originator and the AIGP,
Accumulated Interior Gateway Protocol.
Now, there's not much to the originator.
Basically, a router is going to look
at a prefix or an NLRI that's coming inbound,
and if it originated that prefix or NLRI,
it's going to choose what it originated.
Otherwise, it's going to pick the NLRI that's
being advertised to it based on some other criteria.
In fact, let's jump on the whiteboard real quick. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
In fact, let's jump on the whiteboard real quick.
In a scenario where R1 advertises its loopback
through IBGP to R2, who then advertises it down
to R3, who then advertises it back to R1,
R1 is going to be able to look at this advertisement that's
coming in and saying, wait a minute.
I originated this with my network statement,
and it knows to pick its own in NLRI, the one that
has a next hop of 0.0.0.0.
The third command of BGP's best path algorithm
looks at the following characteristics. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
looks at the following characteristics.
For the NLRI, it's looking at who the originator was.
So if I put a little a here, if R1 originated this loopback
address with either the network statement or redistribution,
this is the criteria that would win.
If R1 originated this with the aggregate address command,
this is the next criteria that would win.
And then lastly, if R1 didn't originate it
and it was learned on an inbound NLRI, that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and it was learned on an inbound NLRI, that
is the next criteria.
That really is all there is to say
about the originator and the third selection criteria.
So first, there's weight.
Then there's local preference.
Then we're looking at if we originated these with a network
statement, a redistribute statement,
or an aggregate address statement,
or if this was an inbound NLRI.
So with that one under our belt, let's move
on to the fourth criteria, and that's AIGP.
It's been suggested numerous times that BGP actually
use the underlying IGP's metric in order WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
use the underlying IGP's metric in order
to determine the best path.
But this isn't feasible because when Carrier A peers
with Carrier B, what happens if Carrier A is running OSPF
and Carrier B is running EIGRP?
We don't have control over our peers' interior gateway
protocols.
And therefore, the metric just falls apart
when it moves from one peer to another.
However, if we are a service provider
and we have multiple autonomous systems here, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and we have multiple autonomous systems here,
we can control the IGP that is running
in each one of these autonomous systems.
So for instance, if all of these are running OSPF,
we can configure BGP as it's moving
from one autonomous system--
from one of our autonomous systems
to the next autonomous systems to factor in the IGP's metric
and pass that metric along from one device to the next.
This is using something called-- well,
I'm just going write it here--
AIGP, Accumulated Interior Gateway Protocol. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
AIGP, Accumulated Interior Gateway Protocol.
Each router has to agree that they
are going to run AIGP the whole way through the path.
That way, the metric can be accumulated
as it moves from one autonomous system to the next.
Configuring AIGP is very easy.
It's one command.
Now, I would love to jump in the virtual lab
and show you how to configure AIGP, say, from our 3 up to R4,
except that the commands to enable AIGP are actually
relatively new. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
relatively new.
And older versions of iOS simply don't support
a AIGP or this new command.
But perhaps in an exam environment,
you may encounter one of the newer versions of iOS,
and you need to know about this command.
All it takes to enable AIGP and start passing IGP metrics back
and forth is the neighbor statement, our neighbor's IP
address--
I'm just going to put this in a little caret here--
then AIGP.
That's it.
So for instance, we ran that command on R3
with regards to R4. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
with regards to R4.
Then we jump over to R4 with regards to R3,
and these two would detect that our peers' capabilities include
AIGP.
So if I jump over to the virtual lab really quick,
clear the screen--
and I'm going to show BGP IPv4 unicast neighbor.
I'll call out my specific neighbor of R4.
That's 34.4.
Sorry about that.
Right here under the for address family IPv4 unicast,
you would be able to see one of the capabilities listed WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
you would be able to see one of the capabilities listed
right in this section, that it is AIGP enabled.
So as routes get advertised all the way down
to R4 or maybe all the way up to R5,
it would be accumulating a metric,
and that would be the fourth criteria
that it determines as the best path forward.
So that's been the originator in AIGP.
I hope this has been informative for you,
and I'd like to thank you for viewing.