So, let's turn our attention to layer 3.
And so, we've got a layer 3 device here and a packet is going to get evaluated
and we
need to figure out what interface to send this packet out.
But keep in mind, when it comes to layer 3, I not only need to know the
outgoing interface,
I also need to know what the next hop is.
In most cases, this next hop, which is a layer 3 next hop, in other words, an
IP address
for what the next device is, is going to be used to actually look up the layer WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
for what the next device is, is going to be used to actually look up the layer
2 address
for my new layer 2 frame.
Because this packet is going to have its layer 2 ethernet header, let's just
say it's ethernet,
it's going to have this layer 2 header stripped off, evaluate the layer 3, move
it to the
destination interface, but now this packet, which is about to get sent out, is
going to
need to be reconstructed with a new layer 2 header as it gets sent to the next
device WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
device
in the path.
And so, we've got this layer 3 device here, packet arrives, going to send it
out to or
out this interface, but again, what is this device that I'm sending it to?
That would be the next hop layer 3 device or address, which will lead me to
decipher
or figuring out what the layer 2 address would be.
And usually I'm just going to use ARP or IPv6 neighbor discovery in order to
figure out
what that is based on the layer 3 next hop. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
what that is based on the layer 3 next hop.
So this is the process that we're going to use, so how do we get from point A
to point
B?
Well, we're going to start with this concept of the routing table.
We refer to the routing table a lot, and Cisco has a fancier word for this, and
I guess
the industry at large does, and the fancy word for the routing table is known
as the
routing information base, otherwise known as the rib. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
routing information base, otherwise known as the rib.
So this routing information base is how all of the data gets stored in a
structured way
and allows us to perform a lookup.
Figure out where this packet should go, and again, two key pieces of
information here,
outgoing interface, as well as the layer 3 next hop address.
Another important aspect of the routing table is that we have a routing table
on a per VRF
basis.
Sort of like how we had a cam table per VLAN at layer 2. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Sort of like how we had a cam table per VLAN at layer 2.
At layer 3 we have the exact same concept, but it's a routing table per VRF now
, which
is that virtual routing and forwarding instance, basically a way for us to
carve up a layer
3 device in the multiple layer 2 domains, in the same way that VLANs carve a
layer 2
device up in the multiple layer 2 domains.
So yes, we have a routing table per VRF.
Now if we don't specify which VRF we're using, then most of everything we do is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now if we don't specify which VRF we're using, then most of everything we do is
going to
go into the default VRF.
That's a pretty common situation.
If I do a show IP route on a Cisco device, it's going to assume we meant the
default
VRF, we have to actually intentionally specify other VRFs if we want to use
them.
So the question is, how does the routing table get populated?
Where is all of this information coming from?
Well, it's going to aggregate data from all of our other routing protocols.
So I might have, for example, OSPF running, and it's going to feed information WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I might have, for example, OSPF running, and it's going to feed information
into the
routing table.
I might have EIGRP running, I might have RIP running, and by the way, I might
actually
also have static routes included here as well.
Yeah, I might have a layer 3 device that's running all three of these different
protocols,
and they're all feeding the same routing table or the same rib.
But once again, we have to ask this question of how are we populating the
routing table
then?
What if they're all providing information on how to reach a specific route? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
What if they're all providing information on how to reach a specific route?
Well, this is where we have to worry about administrative distance.
And if we have the administrative distance helping us to figure this out, then
we have
to remember how exactly this works, which is that the lowest administrative
distance
or AD is going to win.
Now here's the very important part in all of this.
This is only going to apply only if the routes are identical, meaning that we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This is only going to apply only if the routes are identical, meaning that we
have the exact
same network ID and the exact same subnet mask.
So in other words, if we had, for example, 10.0.0.0/24, and then we also have
10.0.0.0/25,
these are completely different subnets and entries into the rib as far as that
device WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
device
is concerned.
So if one of these, let's say, is coming from RIP and the other one is coming
from OSPF,
well, guess what?
From a human perspective, these might look like the same network, but from a
router perspective,
looking at the mask as well, we see they're two completely different routes.
And so both of these would get installed into the routing table at the same
time.
So let's have a quick review about administrative distance values, at least as
far as some of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
far as some of
the common ones, and keep in mind, these are the default values.
We can always change these in our environment if we so desire.
But a static route is going to have an administrative distance of one.
EBGP external BGP is going to have an AD of 20.
EIGRP is 90.
OSPF is 110.
RIP is 120.
And then we might have an IBGP or internal BGP show up, which would be 200. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then we might have an IBGP or internal BGP show up, which would be 200.
So generally speaking, we are going to have an order of operations in here for
our IGP,
these are interior gateway protocols, BGP is split between the EBGP and IBGP.
We always want to trust an IGP over IBGP, which is why it's so high.
And then static, the assumption here is we're for including static routes that
that is meant
to override anything that's happening from a dynamic perspective. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to override anything that's happening from a dynamic perspective.
But again, we're always going to prefer the lower administrative distance.
And so EIGRP is generally preferred over OSPF.
We just have to remember the big caveat here, which is that the subnet has to
match perfectly
in order for those to get compared.
Otherwise they will both be installed.
Now, lastly, again, we have to ask this question of how do these routing
protocols, how do
these learn what's going on?
I mean, how do we populate them? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I mean, how do we populate them?
Or how are they learning about routes?
Well, on the back end here, each one of these, at least the dynamic routing
protocols, not
the static side, but OSPF and EIGRP, they're both maintaining their own sets of
data.
And this data is going to be compiled and taken a look at and evaluated within
the routing
process.
This is where we use the cost or metric. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This is where we use the cost or metric.
So a metric is an EIGRP term, OSPF is going to use the phrase cost, but we're
going to
evaluate it within the routing protocol process without comparing back and
forth, because
I have no way of comparing EIGRP metric with OSPF cost.
The two can't possibly intermix with one another, which is why we have
administrative
distance to compare routing protocols.
This information is stored in the OSPF database and the EIGRP topology table. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This information is stored in the OSPF database and the EIGRP topology table.
Notice that these terms are not established as if they're standardized.
Each protocol is going to have its own way of storing data and figuring things
out, but
that all happens before we ever consider pushing anything down to the routing
table.
This is the last part of the process.
Once OSPF and EIGRP, once they decide which routes are best from their
perspective, they WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
perspective, they
will attempt to push things down to the routing table.
And this is where we have to compare with other routing processes to find out
if administrative
distance is going to come into play.
One thing worth noting in all of this is we've said that the global routing
table here is
known as the rib.
Every now and again, we will hear these tables referred to as their own little
ribs.
Cisco doesn't usually use this term.
If Cisco is saying rib, they're usually referring to the global routing table. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If Cisco is saying rib, they're usually referring to the global routing table.
Something to keep in mind, but in certain documents, you might see something
called in the OSPF
rib or something like that.
It's really talking about the OSPF database at that point.
So as far as the last part of this process is concerned, what are we looking at
?
Well, again, if they're different routes, then they're both going to get
installed or
in that case.
But if it is a 10.0.0, let's just say they're both the same thing. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But if it is a 10.0.0, let's just say they're both the same thing.
They have the same subnet mass 24/24/24.
One is OSPF.
One is EIGRP, which yes, from a Cisco CLI perspective is labeled with a D there
.
That would be EIGRP.
Well, in this case, OSPF is going to lose out to EIGRP because EIGRP has the
lower administrative
distance.
So the OSPF route does not get installed.
The EIGRP route does get installed.
Whereas again, if we did have a different subnet in here, like a slash 25 for O WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Whereas again, if we did have a different subnet in here, like a slash 25 for O
SPF, well,
both of these would end up getting installed into the routing table.
And so now we have to say, well, which of these routes are we going to pick?
The answer is always the same.
And it has nothing to do with administrative distance.
It is always the longest prefix match, meaning the prefix that has the most
bits that match WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
bits that match
the destination.
So usually this can be related back to the most specific or the smallest subnet
that
applies.
So if I'm sending to 10.0.0.1 here, well, slash 24, that has 256 different
possibilities.
A slash 25 is 128.
As long as this fits into both of these and it does in this situation, well, I
'm going
to take the most specific path.
That would be the OSPF route. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
That would be the OSPF route.
And so at that point, once the once the routes have been installed in the
routing table, administrative
distance has already been taken into account.
We are no longer concerned with administrative distance.
I am always going to take the longest prefix match at that point.
[BLANK_AUDIO]