|
0:00:14
|
So, in this section here, we're gonna
|
|
0:00:19
|
that do not relate directly to the
|
|
0:00:23
|
So, in this section, we'll talk about things like,
|
|
0:00:27
|
how do the switching paths work, what are the
|
|
0:00:33
|
depending on whether we're looking
|
|
0:00:39
|
or multipoint in the main interfaces
|
|
0:00:41
|
versus point-to-point links and how that's going
|
|
0:00:48
|
We'll also talk about some routing
|
|
0:00:52
|
Like doing static routing, policy
|
|
0:00:58
|
how the enhanced object
|
|
0:01:01
|
and how this can be integrated
|
|
0:01:04
|
and the embedded event manager
|
|
0:01:06
|
in order to give some intelligence
|
|
0:01:12
|
So, on two things like static
|
|
0:01:18
|
Some of the new features that we
|
|
0:01:24
|
So, to start, regardless of
|
|
0:01:28
|
whether we're using
|
|
0:01:32
|
or whether we're using static
|
|
0:01:34
|
The router is always gonna go
|
|
0:01:39
|
when it is trying to move packets
|
|
0:01:43
|
First and foremost, everytime
|
|
0:01:47
|
it's gonna look at the destination address to
|
|
0:01:53
|
that I eventually need to
|
|
0:01:56
|
This is what the job of the
|
|
0:01:58
|
So, whether we're talking
|
|
0:02:02
|
which is also called the "Routing
|
|
0:02:06
|
or we're talking about the forwarding information
|
|
0:02:12
|
the ultimate goal of this is to figure out when
|
|
0:02:18
|
Now, once the routing
|
|
0:02:22
|
it's out of the routing processes hands.
|
|
0:02:24
|
So, the actual moving of
|
|
0:02:28
|
and then, the ultimate
|
|
0:02:30
|
those are outside of the scope
|
|
0:02:34
|
The second of this 3-step process is the
|
|
0:02:40
|
where the router is actually moving
|
|
0:02:44
|
Now, it's important to know
|
|
0:02:47
|
between the routing process
|
|
0:02:50
|
because the switching process will be
|
|
0:02:55
|
or fast switching, or CEF switching.
|
|
0:02:57
|
This is where we define
|
|
0:03:01
|
and whether the router actually has
|
|
0:03:05
|
to move the frame between the interfaces,
|
|
0:03:08
|
or whether we're gonna use the
|
|
0:03:13
|
or at the individual line card or port depending on
|
|
0:03:20
|
Then, lastly, we have the encapsulation process.
|
|
0:03:23
|
This is where the router is going
|
|
0:03:27
|
Now, we talked about previously
|
|
0:03:33
|
when we were doing the
|
|
0:03:37
|
or the Layer 3 switch virtual interfaces, or the
|
|
0:03:43
|
the main difference between
|
|
0:03:48
|
and the Layer 3 routing process
|
|
0:03:53
|
we are rebuilding the Layer 2
|
|
0:03:59
|
So, this is what allows us to receive a packet
|
|
0:04:04
|
forward it out on Ethernet interface.
|
|
0:04:07
|
Because we know that frame relay and Ethernet
|
|
0:04:12
|
so, it's up to the router to be
|
|
0:04:18
|
When we previously looked
|
|
0:04:21
|
where the switches are moving packets
|
|
0:04:26
|
the Layer 2 switch is not
|
|
0:04:29
|
So, it does a Layer 2 lookup based on
|
|
0:04:34
|
but it's not actually changing
|
|
0:04:38
|
So, from here, when we talked about
|
|
0:04:42
|
the devices in the network are rebuilding the
|
|
0:04:48
|
This ultimately means that
|
|
0:04:51
|
what is the interaction between
|
|
0:04:55
|
We looked at this a little bit
|
|
0:05:00
|
for IP over Ethernet
|
|
0:05:02
|
where the used the IP Address
|
|
0:05:06
|
Then, IP over the non-broadcast
|
|
0:05:09
|
where we either had to use inverse ARP,
|
|
0:05:14
|
or use point-to-point interfaces,
|
|
0:05:17
|
whether they're point-to-point frame relay
|
|
0:05:22
|
to avoid any of those Layer 2
|
|
0:05:27
|
So again, our first portion
|
|
0:05:30
|
between the interfaces is
|
|
0:05:34
|
Now, when the router
|
|
0:05:37
|
first thing it does is look at
|
|
0:05:41
|
and it's gonna do a lookup against either
|
|
0:05:46
|
to figure out what is the
|
|
0:05:51
|
versus a routing entry that I have,
|
|
0:05:54
|
and the actual destination of the packet.
|
|
0:05:59
|
So, in this case, if a packet is received
|
|
0:06:04
|
the router wants to know bit-wise, if I were to do
|
|
0:06:12
|
what is the one that's gonna
|
|
0:06:15
|
So here, if we were to have three routing
|
|
0:06:21
|
1.0.0.0/8, 1.2.0/16 and 1.2.3.0/24,
|
|
0:06:29
|
the router would choose the third entry,
|
|
0:06:35
|
Where the longest match means that it
|
|
0:06:39
|
for the routing entry
|
|
0:06:43
|
Now, we'll see that when we
|
|
0:06:46
|
We're gonna spend a lot of time
|
|
0:06:50
|
and how we can use it for different
|
|
0:06:55
|
So, things like summarization
|
|
0:07:01
|
Linking different subnets versus summaries
|
|
0:07:05
|
And then, also with the BGP
|
|
0:07:09
|
how we can use this longest match principle
|
|
0:07:13
|
is gonna forward through the network.
|
|
0:07:16
|
So, regardless of any of the other attributes
|
|
0:07:22
|
the router is always gonna
|
|
0:07:25
|
So, this would then be independent of attributes
|
|
0:07:32
|
So, if I have a route that is 1.2.3.4/32,
|
|
0:07:41
|
and the metric is whatever
|
|
0:07:44
|
the router would always prefer that
|
|
0:07:50
|
Where the longest match possible in
|
|
0:07:56
|
And the shortest match would be
|
|
0:08:00
|
So, essentially, the default route is our last
|
|
0:08:09
|
Now, once the router finds the
|
|
0:08:14
|
the next job is to figure out what is the actual outgoing
|
|
0:08:20
|
And this is done through what is
|
|
0:08:24
|
The Route Recursion Process is
|
|
0:08:28
|
and figure out what is the next hop
|
|
0:08:34
|
In this case, we have multiple next
|
|
0:08:40
|
So, we have the... It says, "The destination
|
|
0:08:48
|
At this point, the router needs to know now,
|
|
0:08:55
|
So, this is what is considered
|
|
0:08:58
|
Anytime we need to do the
|
|
0:09:01
|
in order to get to the
|
|
0:09:04
|
those types of lookups
|
|
0:09:09
|
Now, it essentially doesn't matter how
|
|
0:09:13
|
There will eventually be some finite limit to the
|
|
0:09:21
|
And in which case,
|
|
0:09:24
|
we will see there's an error
|
|
0:09:27
|
and the router basically knows that there's
|
|
0:09:33
|
But under normal circumstances, the router
|
|
0:09:37
|
as long as the destination eventually
|
|
0:09:42
|
Or a logical interface, basically, any link
|
|
0:09:49
|
So, in this case, we have
|
|
0:09:52
|
5.6.7.8 points at 9.0.1.2,
|
|
0:09:56
|
which then points at 3.4.5.6,
|
|
0:09:58
|
which eventually points at the
|
|
0:10:04
|
So then, the router will infer
|
|
0:10:09
|
1.2.3.4 should use Fast Ethernet
|
|
0:10:16
|
Once the routing process
|
|
0:10:20
|
found both the longest match
|
|
0:10:23
|
the routing process is done.
|
|
0:10:26
|
At this point, we then hand
|
|
0:10:30
|
the packet over to
|
|
0:10:33
|
which is actually in-charged of moving
|
|
0:10:41
|
Now, in the case if there
|
|
0:10:45
|
for a particular destination,
|
|
0:10:48
|
then, the router is gonna need to choose,
|
|
0:10:52
|
Or, if potentially, if I have multiple ones, then,
|
|
0:11:00
|
But under normal default processing,
|
|
0:11:03
|
the router first is gonna wanna know where
|
|
0:11:07
|
Are they from the same
|
|
0:11:09
|
Whether this be static routing,
|
|
0:11:13
|
Or if they came from different routing
|
|
0:11:19
|
This is gonna determine, do we use the metric as
|
|
0:11:26
|
The metric value would only be considered
|
|
0:11:28
|
if the multiple longest matches are
|
|
0:11:33
|
Whereas the distance is compared if they
|
|
0:11:40
|
Now, the metric obviously is gonna be dependent
|
|
0:11:46
|
Where OSPF is using its cost value.
|
|
0:11:51
|
RIP is using the hop count. This is why we
|
|
0:11:56
|
because they're only locally
|
|
0:12:01
|
This means that OSPF has no way
|
|
0:12:06
|
portions of the metric that
|
|
0:12:11
|
So, only if we have two
|
|
0:12:14
|
then would we look at
|
|
0:12:19
|
For any different protocols,
|
|
0:12:22
|
if one is OSPF, one is EIGRP, then, we're gonna
|
|
0:12:28
|
Where the distance values,
|
|
0:12:32
|
the first would be
|
|
0:12:38
|
A connected link has
|
|
0:12:42
|
This means that if we actually
|
|
0:12:46
|
with an IPv4 address or an IPv6 address
|
|
0:12:50
|
the router is always
|
|
0:12:53
|
There's no way that we can preempt
|
|
0:13:00
|
Again, assuming that the
|
|
0:13:05
|
Then, we have a static route,
|
|
0:13:08
|
which has a distance
|
|
0:13:12
|
Then, at 5, we have the
|
|
0:13:18
|
So, if we were to configure the IP
|
|
0:13:22
|
at the link level, by default,
|
|
0:13:26
|
Then, we go to 90 for
|
|
0:13:31
|
110 for OSPF.
|
|
0:13:35
|
120 for RIP.
|
|
0:13:40
|
170 for EIRGP external.
|
|
0:13:47
|
So, this is for our IGPs.
|
|
0:13:49
|
Between the EIRGP summary
|
|
0:13:53
|
we would have 20 in there
|
|
0:13:58
|
and 200 at the end for
|
|
0:14:05
|
So, if we look at the way that
|
|
0:14:09
|
it means that a manually
|
|
0:14:12
|
this is always gonna
|
|
0:14:16
|
over any dynamically learned information whether it's
|
|
0:14:23
|
Then, from an external
|
|
0:14:26
|
the router would always prefer an external
|
|
0:14:34
|
Now, the logic behind this
|
|
0:14:37
|
is that if you are learning
|
|
0:14:40
|
it means that the route is not part of you own network.
|
|
0:14:46
|
Because if it was part
|
|
0:14:49
|
you should be learning it
|
|
0:14:55
|
So, EBGP routes should be preferred over
|
|
0:15:00
|
because we don't wanna route
|
|
0:15:03
|
we wanna route towards
|
|
0:15:06
|
Then, for the IGPs, we would
|
|
0:15:12
|
Then, over EIGRP external routes.
|
|
0:15:17
|
We'll see later when
|
|
0:15:20
|
the EIGRP process does try to
|
|
0:15:25
|
by making a distinguished, i mean, between
|
|
0:15:32
|
The OSPF process and the RIP
|
|
0:15:36
|
Where OSPF, we could configure
|
|
0:15:41
|
to prefer the internal OSPF prefixes
|
|
0:15:47
|
but by default, they're all gonna be
|
|
0:15:51
|
We'll see when we get into the
|
|
0:15:56
|
because from a path selection point of
|
|
0:16:01
|
we would always choose the intra-area routes over
|
|
0:16:09
|
So, if OSPF goes through the path
|
|
0:16:13
|
it already means that there were no intra or
|
|
0:16:20
|
However, we could run into a case
|
|
0:16:22
|
with redistribution, that loops can occur with
|
|
0:16:29
|
because we don't distinguish the
|
|
0:16:36
|
Now, RIP has no option for this.
|
|
0:16:37
|
There's no difference between an internal route
|
|
0:16:42
|
So, for the vast majority
|
|
0:16:46
|
they're gonna be due to an interaction
|
|
0:16:51
|
Whether the RIP in OSPF, or RIP in EIGRP.
|
|
0:16:55
|
Because RIP is not
|
|
0:16:57
|
with the way that it's making
|
|
0:17:04
|
Now, there's a question here...
|
|
0:17:07
|
"For the EIGRP summary,
|
|
0:17:10
|
with the distance of 5,
|
|
0:17:13
|
the summary is locally significant, would
|
|
0:17:18
|
So, in this case, it's kind of a corner case scenario
|
|
0:17:27
|
But with the EIGRP summaries, you can do
|
|
0:17:33
|
where you can prefer different routes
|
|
0:17:40
|
So, we could configure an EIRGP
|
|
0:17:45
|
than other equal matches
|
|
0:17:48
|
We'll take a look at that in more detail when
|
|
0:17:57
|
But the overall key points here
|
|
0:18:00
|
are that the connected interfaces
|
|
0:18:03
|
followed by the static routes.
|
|
0:18:05
|
Then, external BGP,
|
|
0:18:08
|
the IGPs, and then internal BGP.
|
|
0:18:12
|
Because likewise, from
|
|
0:18:15
|
if we were learning a route
|
|
0:18:18
|
it means that it's most likely
|
|
0:18:21
|
And we would prefer to use our IGP over
|
|
0:18:28
|
So again, that's why EBGP is the
|
|
0:18:33
|
followed by the IGPs and then,
|
|
0:18:39
|
Okay, there's a question here,
|
|
0:18:46
|
versus one to the interface?"
|
|
0:18:51
|
Now, in a lot of books out
|
|
0:18:55
|
they list a static route to the
|
|
0:19:01
|
where technically, all static routes are
|
|
0:19:05
|
And we'll see that today when we
|
|
0:19:08
|
Changing of the administrative distance to do
|
|
0:19:13
|
There's no way to set something
|
|
0:19:17
|
So, the actual connected link is always zero,
|
|
0:19:21
|
Whether you point the static route
|
|
0:19:25
|
both of those are gonna get
|
|
0:19:28
|
So again, when we're looking at
|
|
0:19:32
|
metric is gonna be when we have multiple
|
|
0:19:35
|
where distance is from
|
|
0:19:41
|
So next, once the routing process is done,
|
|
0:19:46
|
As I mentioned, this is where we would
|
|
0:19:50
|
fast switching, or CEF switching.
|
|
0:19:51
|
Where CEF switching should be the
|
|
0:19:57
|
So, any new version is going
|
|
0:20:01
|
which would be preferred because it has
|
|
0:20:07
|
than either of the fast switching or route cacheing
|
|
0:20:13
|
And then, the process switching, which means
|
|
0:20:19
|
by the router's general purpose CPU.
|
|
0:20:23
|
Now, we will see as we're doing different type of
|
|
0:20:28
|
that the router will process switch locally
|
|
0:20:38
|
Whereas in transit traffic, packets that are coming
|
|
0:20:44
|
those are gonna be sent to
|
|
0:20:49
|
This will also mean that when we
|
|
0:20:53
|
like, Debug IP Packet, Debug
|
|
0:20:57
|
Debug IP Packet Detail.
|
|
0:20:59
|
The output that shows up is by default only
|
|
0:21:08
|
If we do want to see transit
|
|
0:21:13
|
then, we would need to
|
|
0:21:16
|
We could either do this by saying,
|
|
0:21:20
|
Or at the interface level,
|
|
0:21:23
|
that would disable CEF
|
|
0:21:29
|
Then, likewise, when we get into multicast,
|
|
0:21:35
|
we would say, No IP M Route
|
|
0:21:42
|
Now, for the CEF process, there's really not
|
|
0:21:47
|
If you look at the Show IP Interface, that's gonna
|
|
0:21:52
|
We can also look at the CEF table to figure out
|
|
0:21:58
|
And also, the very last verification
|
|
0:22:03
|
for both the source and the
|
|
0:22:09
|
This can be useful if we're doing any type of
|
|
0:22:16
|
It will tell is based on the
|
|
0:22:19
|
and the binary logic that
|
|
0:22:23
|
what is the outgoing interface
|
|
0:22:28
|
traffic result?
|
|
0:22:30
|
So, we'll see that with CEF, we can load balance
|
|
0:22:35
|
but both of them at the same
|
|
0:22:41
|
So, the CEF process can use
|
|
0:22:46
|
like the TCP ports, the UDP ports in order to make
|
|
0:22:55
|
So, they key point being here
|
|
0:22:57
|
that if the routing protocol is offering
|
|
0:23:04
|
meaning that we have two OSPF routes of unequal
|
|
0:23:10
|
then, it would be up to the CEF process to figure
|
|
0:23:16
|
So, just because there's multiple
|
|
0:23:19
|
it doesn't actually mean that both of them
|
|
0:23:23
|
It's up to the underlying switching process
|
|
0:23:28
|
There's a question here,
|
|
0:23:31
|
"I know CEF builds a table, but what does fast
|
|
0:23:38
|
Now, the...
|
|
0:23:40
|
The key behind how the CEF process
|
|
0:23:47
|
Meaning that we now exactly how long it's
|
|
0:23:53
|
Regardless of what the
|
|
0:23:56
|
The reason why is that CEF internally
|
|
0:24:03
|
where they're based on the
|
|
0:24:08
|
So, assuming we're talking about
|
|
0:24:13
|
So, we know that for
|
|
0:24:17
|
we have four different octets
|
|
0:24:21
|
or 32 bits.
|
|
0:24:23
|
So, we have octet A, B, C and D.
|
|
0:24:28
|
Within the scope of the CEF process,
|
|
0:24:30
|
this means that we have an internal data
|
|
0:24:37
|
where inside this, we have 255 child entries
|
|
0:24:49
|
Then, inside this second table,
|
|
0:24:51
|
so the second level of hierarchy.
|
|
0:24:53
|
We then likewise have
|
|
0:24:58
|
all the way down to 255,
|
|
0:25:01
|
and then, again, for the fourth octet.
|
|
0:25:05
|
So, 1 through 255.
|
|
0:25:10
|
So, what this means programatically
|
|
0:25:14
|
is that when we're trying to figure out what is
|
|
0:25:19
|
it means that we have to
|
|
0:25:23
|
What's the first octet?
|
|
0:25:25
|
Under the first octet, data structure,
|
|
0:25:30
|
Which would be the second octet, then,
|
|
0:25:37
|
So, it's deterministic in a manner that
|
|
0:25:41
|
Now, for the other switching
|
|
0:25:46
|
we do the entire lookup all at once
|
|
0:25:50
|
top-down based on how
|
|
0:25:55
|
So, if we're trying to get
|
|
0:25:58
|
and we look into the routing table
|
|
0:26:04
|
5.6.7.8, 9.10.11.12,
|
|
0:26:08
|
and we may find that it takes us 200,000 entries down
|
|
0:26:18
|
it means that the router actually has to do 200,000
|
|
0:26:25
|
So, with the process switching process,
|
|
0:26:29
|
the lookup is not deterministic, because it depends
|
|
0:26:35
|
and how they're organized.
|
|
0:26:37
|
And when we actually look at
|
|
0:26:41
|
it's not very easy to predict how
|
|
0:26:48
|
So, it has to do with, what's the order that the routes were
|
|
0:26:55
|
So, there's no... From out point of view,
|
|
0:26:59
|
So, with process switching, you could have
|
|
0:27:05
|
and your destination
|
|
0:27:08
|
So, this is your best case scenario where it
|
|
0:27:13
|
But it could likewise be the very
|
|
0:27:16
|
which could be 300,000
|
|
0:27:22
|
Now, the key point about this is that
|
|
0:27:27
|
So, everytime the router
|
|
0:27:31
|
it would look at the routing table in order
|
|
0:27:37
|
Now, with the fast
|
|
0:27:41
|
once the process switching figures
|
|
0:27:46
|
then, we keep a route cacheing table
|
|
0:27:52
|
So, if the router looked at the table
|
|
0:28:00
|
a copy of this is kept in the route cache.
|
|
0:28:04
|
So, if the subsequent lookup comes from A.B.C.D,
|
|
0:28:13
|
So, in this case, the fast switching
|
|
0:28:18
|
where we don't have cacheing entry until we have
|
|
0:28:25
|
Whereas with the CEF process,
|
|
0:28:30
|
So, when we're building
|
|
0:28:33
|
learning and routing information from OSPF,
|
|
0:28:39
|
look at the longest match
|
|
0:28:43
|
and that how the result
|
|
0:28:49
|
Now, when we get to larger scale
|
|
0:28:55
|
the actual CEF table
|
|
0:28:58
|
or the forwarding information
|
|
0:29:02
|
this is actually installed
|
|
0:29:06
|
which means that when a packet
|
|
0:29:09
|
it doesn't have to ask the central CPU,
|
|
0:29:14
|
but also, it doesn't need to reference
|
|
0:29:18
|
So, essentially, the CEF table is on a per-port basis,
|
|
0:29:25
|
versus to go to some sort of
|
|
0:29:30
|
Now, there are a lot of
|
|
0:29:35
|
It's kind of outside the scope of the routing
|
|
0:29:39
|
the theory of how the
|
|
0:29:43
|
One of the good resources
|
|
0:29:46
|
Inside Cisco IOS Software
|
|
0:29:56
|
This one here.
|
|
0:30:01
|
And then, also there's a
|
|
0:30:08
|
So, if you search for
|
|
0:30:17
|
This one here. So, there's a full book
|
|
0:30:23
|
And one of the guys who wrote or was
|
|
0:30:30
|
both inside Cisco IOS Software
|
|
0:30:33
|
Russ White, he's the program
|
|
0:30:38
|
The Cisco Certified
|
|
0:30:41
|
So, both of these
|
|
0:30:43
|
But they're very, very
|
|
0:30:47
|
about how the router does
|
|
0:30:49
|
like the memory management for the
|
|
0:30:53
|
So, it is... Most of it
|
|
0:30:55
|
but it's definitely pretty interesting to read to figure
|
|
0:31:05
|
There is a question, "Is it possible to view
|
|
0:31:12
|
We should be able to see
|
|
0:31:17
|
So, we'll see when we configure
|
|
0:31:22
|
these entries should not
|
|
0:31:26
|
If we were to disabled CEF, we would
|
|
0:31:31
|
switching method,
|
|
0:31:34
|
which would be fast switching
|
|
0:31:38
|
So next, once the router
|
|
0:31:41
|
and the switching process has actually
|
|
0:31:45
|
now it's up to the interface
|
|
0:31:51
|
from the Layer 2 header up.
|
|
0:31:54
|
Now, normally, the Layer 3 header
|
|
0:31:59
|
unless we're doing something
|
|
0:32:03
|
or some sort of Layer 3 QoS rewrite.
|
|
0:32:07
|
So, the router is normally just rebuilding
|
|
0:32:11
|
not necessarily the
|
|
0:32:15
|
Now, when we do this,
|
|
0:32:17
|
depending on what type
|
|
0:32:20
|
whether it's Ethernet or a multipoint frame relay
|
|
0:32:27
|
the router may need to know
|
|
0:32:33
|
what is the Layer 2 address that actually
|
|
0:32:39
|
In the case of Ethernet,
|
|
0:32:41
|
the MAC address that is derived from
|
|
0:32:47
|
For multipoint frame
|
|
0:32:49
|
this would either be that the DLCI that
|
|
0:32:54
|
or from a static mapping.
|
|
0:32:58
|
But the key point to remember here
|
|
0:33:02
|
the router is always gonna need
|
|
0:33:07
|
Point-to-point interfaces,
|
|
0:33:09
|
like point-to-point frame relay sub-interfaces,
|
|
0:33:13
|
PPP or HTLC links,
|
|
0:33:15
|
they will not need to go through
|
|
0:33:19
|
because in the case of point-to-point
|
|
0:33:23
|
the same Layer 2 address...
|
|
0:33:26
|
is used for every destination
|
|
0:33:30
|
And for HTLC and PPP,
|
|
0:33:35
|
Because they're both
|
|
0:33:38
|
This means that when
|
|
0:33:41
|
I'm assuming that the only
|
|
0:33:44
|
is the device that's
|
|
0:33:46
|
Because by definition, PPP
|
|
0:33:55
|
Now, the reason that I mentioned this...
|
|
0:33:57
|
is that we'll see depending on how
|
|
0:34:02
|
and how the underlying
|
|
0:34:05
|
There are some design issues that we need
|
|
0:34:10
|
So, we'll see, there's a fundamental difference
|
|
0:34:15
|
versus pointing it
|
|
0:34:18
|
and sometimes, we can end up
|
|
0:34:23
|
Okay, there's a question here,
|
|
0:34:25
|
"When a routing lookup
|
|
0:34:29
|
the GRE encapsulation, would this
|
|
0:34:33
|
So, does this mean that
|
|
0:34:38
|
There would actually be two different
|
|
0:34:41
|
And we will look at this today, we're gonna
|
|
0:34:45
|
But when the routing lookup
|
|
0:34:51
|
we then look at what is
|
|
0:34:54
|
and do a recursive lookup on that.
|
|
0:34:59
|
So, we know based on the fact that
|
|
0:35:03
|
we need the Layer 3 GRE header.
|
|
0:35:06
|
So, GRE is Layer 3 encapsulation,
|
|
0:35:11
|
But then, when we actually go
|
|
0:35:14
|
like if the GRE packet is
|
|
0:35:18
|
we would need to know
|
|
0:35:22
|
What is the next hop that
|
|
0:35:26
|
And then what is the Layer 2
|
|
0:35:31
|
Now, this is gonna bring us to our next point
|
|
0:35:34
|
where we have to make
|
|
0:35:36
|
routing to a next hop value
|
|
0:35:41
|
Now, when we route
|
|
0:35:44
|
this means that the router
|
|
0:35:46
|
what is the outgoing interface
|
|
0:35:51
|
So, if we can figure a static route that says,
|
|
0:35:59
|
the router knows what
|
|
0:36:02
|
it's 1.2.3.4.
|
|
0:36:04
|
But it doesn't know what interface
|
|
0:36:09
|
So now, the router needs
|
|
0:36:13
|
to figure out where is 1.2.3.4 located.
|
|
0:36:17
|
If the router cannot find an interface
|
|
0:36:23
|
it means the route cannot be
|
|
0:36:28
|
So, if 1.2.3.4 was on
|
|
0:36:32
|
it means that this routing entry 10.0.0.0/8,
|
|
0:36:38
|
if the Fast Ethernet
|
|
0:36:41
|
If for some reason the
|
|
0:36:45
|
then the static would be
|
|
0:36:49
|
So, the router does know when the route
|
|
0:36:54
|
It's gonna be based on the
|
|
0:36:59
|
Now, we'll see that this doesn't necessarily mean
|
|
0:37:04
|
So, when we get in to
|
|
0:37:07
|
and the IP SLA and the embeded
|
|
0:37:11
|
we'll see there's some additional intelligence
|
|
0:37:15
|
to make sure that we know
|
|
0:37:19
|
but do we acutally have reachability
|
|
0:37:23
|
So, once the router finds
|
|
0:37:27
|
then it would need to do a Layer 3 to
|
|
0:37:33
|
So, this means that for any packet that is
|
|
0:37:41
|
all packets will use the
|
|
0:37:48
|
Now, if we were to route
|
|
0:37:52
|
it then would mean the router
|
|
0:37:57
|
So, it needs to figure out what's
|
|
0:38:01
|
This is the address that actually
|
|
0:38:04
|
for any Layer 3 packet
|
|
0:38:11
|
Now, under normal circumstances,
|
|
0:38:14
|
because ARP is an
|
|
0:38:17
|
Assuming that that next hop
|
|
0:38:21
|
we shouldn't have any problems
|
|
0:38:24
|
With Ethernet, this
|
|
0:38:27
|
if for some reason,
|
|
0:38:30
|
like we some sort of Layer 2 security
|
|
0:38:34
|
or maybe 1.2.3.4 is not really
|
|
0:38:40
|
in which case, we'll have some sort
|
|
0:38:43
|
to the IP address binding.
|
|
0:38:46
|
The next option would be, if we were
|
|
0:38:52
|
So, instead of routing
|
|
0:38:55
|
we now change
|
|
0:38:57
|
"to get to 10.0.0.0/8, I'm gonna
|
|
0:39:03
|
Now, in this case, the router doesn't
|
|
0:39:07
|
because it already knows that the
|
|
0:39:13
|
What it does not know however,
|
|
0:39:16
|
is what's the actual Layer 2
|
|
0:39:22
|
So, we'll see that for
|
|
0:39:25
|
whether they are Ethernet, Multipoint
|
|
0:39:30
|
it's not a good idea to configure
|
|
0:39:32
|
because it means that the router
|
|
0:39:37
|
for the final destination.
|
|
0:39:40
|
This would then mean, for every
|
|
0:39:46
|
Over Ethernet, we would need
|
|
0:39:50
|
Over Frame Relay, we would
|
|
0:39:53
|
Whether this is coming from inverse
|
|
0:39:57
|
the Layer 2 resolution is
|
|
0:40:01
|
not for the intermediate
|
|
0:40:10
|
Now, we can actually take both the
|
|
0:40:14
|
And routing to the multipoint
|
|
0:40:19
|
Which means that we're manually
|
|
0:40:23
|
Plus we're telling them who is
|
|
0:40:27
|
that the packet should be
|
|
0:40:30
|
So, if you use both
|
|
0:40:32
|
it's a little bit more efficient
|
|
0:40:36
|
But assuming that we're doing
|
|
0:40:38
|
it's not really gonna matter,
|
|
0:40:42
|
or the next hop
|
|
0:40:44
|
It's only really gonna
|
|
0:40:47
|
this option here where we point the route
|
|
0:40:52
|
Then the third option we would have
|
|
0:40:55
|
is if we're routing directly to the interface
|
|
0:41:00
|
Now, since we're already telling the
|
|
0:41:03
|
we don't need to do
|
|
0:41:06
|
Since the interface
|
|
0:41:09
|
it also means that Layer 2
|
|
0:41:13
|
So, if this is were a point-to-point
|
|
0:41:16
|
the router would already know based on
|
|
0:41:21
|
what's the Layer 2 address
|
|
0:41:23
|
when we actually
|
|
0:41:26
|
So, out of any of the three variations,
|
|
0:41:30
|
Because we don't have to do
|
|
0:41:32
|
and we don't have to do the
|
|
0:41:36
|
But the key for this is, it's only
|
|
0:41:40
|
We should never point a
|
|
0:41:44
|
or multipoint frame relay.
|
|
0:41:46
|
But we could point
|
|
0:41:49
|
or a GRE tunnel or a
|
|
0:41:53
|
point-to-point sub-interface.
|
|
0:41:55
|
Because likewise, we don't
|
|
0:41:58
|
we don't need to do
|
