In this Nugget, we're going to talk
about the sixth and the seventh factors
in the BGP best path algorithm selection process.
First up, we're going to be talking about the origin type.
Now, when we talk about origin type with relation
to Cisco routers, we're trying to figure out,
did this come from a network statement,
or was this redistributed from an IGP into BGP?
Jumping on the whiteboard, let me tell you
how this really breaks down.
Now, technically, there are three different origin types,
and they're preferred in this manner. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and they're preferred in this manner.
The first is i, meaning this was originated internally
from an IGP using the network statement.
Anytime that you looked at those AS paths
and you saw something like 500, 400 i, that's what we're
talking about here is the i.
Less commonly used-- in fact, almost impossible
to find on a Cisco router-- is e for an externally learned NLRI.
And the reason why you never see this is because pretty much WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And the reason why you never see this is because pretty much
every route starts somewhere with a network statement
or redistribution.
So you should know that e exists,
but really, the selection criteria comes down
to i or question mark.
Question mark technically means incomplete,
meaning we don't know the entire path of this NLRI
because redistribution occurred somewhere along the way
to pull this route in from a different IGP.
Let's jump into the virtual lab and see this in action. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Let's jump into the virtual lab and see this in action.
I'm on R3 right now, and if I give it a show IP route,
you can see what kind of routes we have here.
Well, immediately, what should draw your attention
is these OSPF learn routes.
Now, you would never want to redistribute
your internal routes into BGP.
This is just for a lab demonstration.
But let's do that.
Let's redistribute these OSPF learn routes into BGP
and then see how our peers receive these routes.
So to get the lay of the land, I'll
give it a show BGP IPv4 unicast. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
give it a show BGP IPv4 unicast.
We'll make sure they're not there currently.
They're not.
And all of the routes that I have are showing the I,
so we know that these routes are what's going to be preferred.
Now, route redistribution from an IGP into BGP
is not as risky as doing it in the reverse.
BGP can have hundreds of thousands of routes.
If we were to redistribute from BGP into IGP,
that could create major problems.
But from BGP Configuration Mode, I
can simply say redistribute OSPF process 1. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
can simply say redistribute OSPF process 1.
And if I give it a question mark,
we can even set a metric, which is what our next topic is
going to be all about.
So let me do that.
I'm also just going to throw in a metric of 30 just
to make something up.
And we'll talk about what role that metric
played in just a moment.
Now BGP has redistributed OSPF into BGP.
So if I exit out of Configuration Mode,
go back to show IPv4 unicast--
excuse me-- BGP IPv4 unicast--
now we see our incomplete paths, don't we? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
now we see our incomplete paths, don't we?
And this means that these routes are also being advertised
outbound towards our neighbors.
So let's jump over to R4, give it a show BGP IPv4 unicast.
And I can quickly identify the differences
between the internally originated NLRIs
that came from a network statement versus ones that were
originated from redistribution.
If there were to be a tiebreaker scenario,
the i's would win over the question marks.
But now it's time to talk about the metric.
Th metric in this case is often referred WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Th metric in this case is often referred
to as the Multi-Exit Discriminator or MED,
but that's what shows up in the metric column when
we advertise routes outbound.
There are a lot of rules and best practices
that go into the metric.
Here's the summary of them.
When R3 redistributed routes into BGP,
it also set the metric of 30 on those routes.
So it advertised a prefix of R2 with a metric of 30,
and it advertised that same NLRI up to R4 with a metric of 30 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and it advertised that same NLRI up to R4 with a metric of 30
as well.
This 30 metric is not what we call transitive.
That means R2 isn't going to forward
the prefix with the metric involved with it.
So R2 did forward the NLRIs, but it omitted the 30 metric
in that advertisement.
So R4 in its BGP table learned about the 172.16 prefixes
from R3 and R2.
R3 originated it with redistribution. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
R3 originated it with redistribution.
The difference now between these is
that R2 will not have a metric, and R3
will have a metric of 30.
The rule of thumb in this case is
to prefer routes that do not have a metric.
That is the default rule.
But if both rules were to have a metric--
maybe this one had a metric of 90--
then the rule is then to prefer the one with the lowest metric.
You can kind of think of it like feasible distance
or OSPF's bandwidth cost.
You'd want the lowest one first. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
You'd want the lowest one first.
So let's jump over to R4 and look at the BGP table
and verify that this is the behavior that occurred.
Back on R4, I'll give it a show BGP IPv4 unicast,
hit space bar a few times.
And I can see the redistributed routes
because they have the question marks here.
And look at this.
The R3 learned routes do indeed have a metric
of 30 set on them here.
But the ones that were preferred and installed
in the routing table were the ones
that were R2 because it didn't contain a metric. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that were R2 because it didn't contain a metric.
So my quiz question to you at this point is,
what were to happen if we went to R2
and then advertised these 172 networks
with a network statement?
Who would win?
Then what would happen if, on R2, we
were to redistribute these 172 network statements into BGP
with a metric of 90?
Who would win then?
I encourage you to stay in the virtual lab
and work through both of those scenarios
so that you really understand the behavior of the origin WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
so that you really understand the behavior of the origin
type and the multi-exit discriminator.
In the meantime, that's been rules number 6 and 7.
I hope that's been informative for you,
and I'd like to thank you for viewing.