|
0:00:12
|
So next, we're gonna look at what are the
|
|
0:00:17
|
besides having these feasible successors in
|
|
0:00:23
|
Now, as I mentioned before, EIGRP can
|
|
0:00:28
|
as long as there is a backup route
|
|
0:00:30
|
for the prefix that you are
|
|
0:00:33
|
So, on our particular case
|
|
0:00:39
|
if the link to router 5 goes down, it should
|
|
0:00:46
|
or however router 3 is routing the traffic,
|
|
0:00:50
|
because have already pre-calculated
|
|
0:00:55
|
So, this is gonna be your number one design
|
|
0:01:00
|
that you need to take into account for EIGRP...
|
|
0:01:02
|
that you wanna make sure you have
|
|
0:01:07
|
that you need your fast convergence for.
|
|
0:01:11
|
Now, if there is not a backup route,
|
|
0:01:14
|
EIGRP uses the query message
|
|
0:01:17
|
to ask other neighbors if they have an
|
|
0:01:24
|
Now, part of the scalability
|
|
0:01:27
|
is that when we send the
|
|
0:01:30
|
we have to wait for a reply
|
|
0:01:34
|
before we can remove the old
|
|
0:01:38
|
or from the database, I should say.
|
|
0:01:42
|
and then recalculate the new path.
|
|
0:01:45
|
There can be circumstances where
|
|
0:01:51
|
that when I send the request out,
|
|
0:01:56
|
within the required amount of time.
|
|
0:01:59
|
This is known as the
|
|
0:02:04
|
situation in EIGRP.
|
|
0:02:07
|
So, it means that we lost the
|
|
0:02:12
|
there is no backup have available,
|
|
0:02:14
|
so we had asked the other neighbors,
|
|
0:02:19
|
They continue to pass these
|
|
0:02:21
|
and if the responses don't come back
|
|
0:02:24
|
you have to reset the neighbors.
|
|
0:02:28
|
So, the loss of one particular destination could
|
|
0:02:34
|
because the router is dropping adjacencies,
|
|
0:02:39
|
Now, to prevent this, there's
|
|
0:02:43
|
that we can reduce the
|
|
0:02:48
|
One is through summarization,
|
|
0:02:51
|
the other is through EIGRP
|
|
0:02:56
|
Now with summarization, this is the work
|
|
0:03:01
|
Or we'll see later like in OSPF or BGP,
|
|
0:03:04
|
where we're taking multiple subnet routes,
|
|
0:03:08
|
and were combining them
|
|
0:03:13
|
With EIGRP, since it is not a link state protocol,
|
|
0:03:17
|
and the routers do not understand
|
|
0:03:21
|
we can summarize on any
|
|
0:03:25
|
The same as in RIP.
|
|
0:03:28
|
So, it's on a per-interface basis that
|
|
0:03:33
|
We'll see when we get to OSPF summarization,
|
|
0:03:37
|
the design requirements are more strict,
|
|
0:03:39
|
because we need to make sure that the
|
|
0:03:43
|
have identical copies of the database.
|
|
0:03:46
|
But in EIGRP, since we're not
|
|
0:03:50
|
we're exchanging just the
|
|
0:03:54
|
we could do the summarization
|
|
0:03:58
|
Now, the actual summary...
|
|
0:04:00
|
is gonna support whatever
|
|
0:04:03
|
So, anything from /0 up.
|
|
0:04:07
|
We saw with RIP Version 3, it had the limitation that
|
|
0:04:13
|
EIGRP does not have that limitation.
|
|
0:04:17
|
Now, when we configure a summary as we would want,
|
|
0:04:22
|
EIGRP is gonna suppress the advertisements
|
|
0:04:28
|
So for example, if we had three routes...
|
|
0:04:38
|
10.0.1.0/24,
|
|
0:04:41
|
10.0.2.0,
|
|
0:04:45
|
and 10.0.3.0,
|
|
0:04:49
|
we could summarize these
|
|
0:04:56
|
Once we do this,
|
|
0:04:59
|
it implies that these other four subnets,
|
|
0:05:02
|
they're no longer going to be
|
|
0:05:07
|
which normally would be the design that we want,
|
|
0:05:10
|
because the purpose of summarization is that
|
|
0:05:15
|
but also we are bounding the query domain.
|
|
0:05:21
|
Now, the way that the query domain works...
|
|
0:05:24
|
is that when the router loses its
|
|
0:05:30
|
so let's say that router...
|
|
0:05:33
|
|
|
0:05:35
|
it's learning a bunch of routesin from BB3.
|
|
0:05:38
|
Okay, let's say it was those 10 prefix
|
|
0:05:43
|
10.0.1.0, 10.0.2.0, and 10.0.3.0.
|
|
0:05:50
|
Okay, all /24.
|
|
0:05:54
|
Now, if one of these routes is lost,
|
|
0:05:57
|
let's say, the first one.
|
|
0:05:59
|
Router 2 is gonna ask its other neighbors,
|
|
0:06:04
|
through the query message,
|
|
0:06:06
|
do you have an alternate route to 10.0.0.0/24?
|
|
0:06:12
|
Now, if this link to BB2 is the only possible
|
|
0:06:21
|
it doesn't make sense that router 2 should be sending
|
|
0:06:28
|
So, if 3 and 5, we know that there is no possible
|
|
0:06:33
|
then, it doesn't make sense to do the query.
|
|
0:06:36
|
One way we can stop this...
|
|
0:06:38
|
is at the link level, from 2 to 3, and from 2 to 5
|
|
0:06:43
|
to advertise a summary of the subnets.
|
|
0:06:54
|
Now, if one of the subnets...
|
|
0:06:56
|
leaves the table,
|
|
0:06:58
|
so router 2 loses reachability to 10.0.0.0/24,
|
|
0:07:03
|
router 2 then sends the query message to 3 and 5.
|
|
0:07:07
|
It says specifically, "Do you have an
|
|
0:07:14
|
However, since router 3 and 5 never
|
|
0:07:23
|
they only have the /22,
|
|
0:07:26
|
they immediately reply back with
|
|
0:07:31
|
and say, "No, there's no one as
|
|
0:07:38
|
So, the device that is doing the summarization...
|
|
0:07:41
|
is the one that is bounding the query domain.
|
|
0:07:44
|
So, based on the fact that router 2 does the
|
|
0:07:50
|
it means that if router 2 loses one of those subnets,
|
|
0:07:53
|
the query message will go out one hop away,
|
|
0:07:56
|
and then, the reply will come immediately back in.
|
|
0:08:00
|
Now, if router 3 previously did have the /24,
|
|
0:08:04
|
it would mean that 3 sends
|
|
0:08:08
|
their neighbors send the... Or excuse, me the queries.
|
|
0:08:13
|
and then, everyone has to wait for
|
|
0:08:17
|
But if we know based on the physical topology,
|
|
0:08:20
|
there's no other possible way
|
|
0:08:23
|
then, it doesn't make sense to
|
|
0:08:30
|
So, it's actually dual functionality here.
|
|
0:08:33
|
It's cutting down on the size the routing table,
|
|
0:08:35
|
but it is also limiting the size of the query domain.
|
|
0:08:42
|
We'll also see that for the
|
|
0:08:46
|
we can selectively choose what particular
|
|
0:08:55
|
because remember, the routing table is
|
|
0:08:59
|
when it is trying to reach a destination.
|
|
0:09:03
|
So, this means that from router 2's perspective,
|
|
0:09:06
|
if it were to advertise to router 3,
|
|
0:09:12
|
10.0.0.0/22, but to router 5, it would
|
|
0:09:26
|
it would mean that all traffic going
|
|
0:09:33
|
would go this way.
|
|
0:09:38
|
Because the routing table is always
|
|
0:09:41
|
regardless of either the metric or the distance.
|
|
0:09:47
|
So, we're not gonna take a look at this
|
|
0:09:52
|
but when we get to OSPF and BGP summarization,
|
|
0:09:55
|
we will take a look at more detail cases of using
|
|
0:10:03
|
for the purpose of traffic engineering.
|
|
0:10:06
|
Also, when we generate the summary in EIGRP,
|
|
0:10:09
|
the administrative distance defaults to 5.
|
|
0:10:12
|
So, it would allow us to do some
|
|
0:10:17
|
where we could prefer...
|
|
0:10:19
|
the summary from other routers or through
|
|
0:10:24
|
the default value that we are configuring.
|
|
0:10:27
|
Now, the reason that you've may
|
|
0:10:31
|
is that EIGRP will automatically
|
|
0:10:36
|
or a route to null zero for the
|
|
0:10:45
|
Now, the case that you would not
|
|
0:10:51
|
would be if we want to fall back
|
|
0:10:55
|
for a subnet that we don't actually
|
|
0:11:01
|
So, let's say for example that we have...
|
|
0:11:05
|
router 1 connected to router to 2,
|
|
0:11:09
|
and both of them have some
|
|
0:11:17
|
On router 1, from this upstream neighbor, we're
|
|
0:11:26
|
and 10.0.1.0/24.
|
|
0:11:30
|
So to our downstream neighbors,
|
|
0:11:33
|
we're advertising an aggregate.
|
|
0:11:41
|
This then implies that when router 1
|
|
0:11:46
|
it will install a route that says
|
|
0:11:55
|
which was a discard route.
|
|
0:11:58
|
What this is used to do...
|
|
0:12:01
|
is prevent the case that if for some reason
|
|
0:12:08
|
that it does not continue to forward traffic...
|
|
0:12:12
|
to someone that does not
|
|
0:12:16
|
So let's say additionally, router 1 has a
|
|
0:12:25
|
In the case that EIGRP is
|
|
0:12:30
|
and router 1 loses the route
|
|
0:12:35
|
router 1 would not be able
|
|
0:12:39
|
as an alternate path to that destination,
|
|
0:12:44
|
because when the /24 route goes away,
|
|
0:12:47
|
router 1's longest match then
|
|
0:12:55
|
So, typically this is what we want, that the
|
|
0:13:01
|
but we can remove the discard route
|
|
0:13:05
|
by setting administrative distance
|
|
0:13:09
|
or by configuring some other route.
|
|
0:13:13
|
Like a static route for the summary that
|
|
0:13:22
|
So, let's take a look at this in...
|
|
0:13:26
|
in our topology.
|
|
0:13:30
|
Now, router 5 is learning the
|
|
0:13:37
|
switch 2 and switch 4. So,
|
|
0:13:43
|
and 150.10.8.0.
|
|
0:13:48
|
So, let's say that we wanna
|
|
0:13:51
|
and we're going to aggregate them together.
|
|
0:13:55
|
So, this would be 150.10.0.0
|
|
0:14:01
|
with a range of 0.0 through 15.255,
|
|
0:14:12
|
which means it's gonna be what mask?
|
|
0:14:15
|
So, 256 minus 15... Actually, it
|
|
0:14:21
|
is 240.
|
|
0:14:23
|
It'd be 255.255.240.0.
|
|
0:14:30
|
So, this would be a /20.
|
|
0:14:34
|
So, we're gonna take this /20 route,
|
|
0:14:37
|
and route 5 is gonna advertise it
|
|
0:14:42
|
and out to the frame-relay.
|
|
0:14:44
|
Now, we could do this assuming that we have
|
|
0:14:50
|
So, if router 5 says, Show IP EIGRP Topology,
|
|
0:14:53
|
150.10.8.0/24,
|
|
0:14:58
|
or 10.0/24.
|
|
0:15:01
|
As long as one of these matters are in there,
|
|
0:15:03
|
then, we would be able to originate the summary.
|
|
0:15:11
|
Let's also say that now, on the link level,
|
|
0:15:14
|
we generate the summary. So, IP
|
|
0:15:19
|
The route is 150.10.0.0/20,
|
|
0:15:28
|
and the same thing on the link to router 4.
|
|
0:15:35
|
So now, if we look at any other neighbor
|
|
0:15:40
|
and we looked at what are our routes
|
|
0:15:43
|
to these particular destinations,
|
|
0:15:45
|
we should see that the longest match is the /20...
|
|
0:15:52
|
that router 5 is originating.
|
|
0:15:55
|
So, it's not gonna change our path selection
|
|
0:15:58
|
if we traced to 150.10.8.8,
|
|
0:16:03
|
we still have to go to router 5,
|
|
0:16:06
|
because that's the only device that has physical
|
|
0:16:11
|
So, the only thing we're doing is saving
|
|
0:16:15
|
and also, if router 5 loses the
|
|
0:16:23
|
when it sends the query messages to the neighbors,
|
|
0:16:26
|
they're immediately going to send the replies
|
|
0:16:31
|
to these destination.
|
|
0:16:34
|
We would see this on router 4 if we said the
|
|
0:16:39
|
or Debug EIGRP Packet...
|
|
0:16:43
|
Queries and Replies.
|
|
0:16:48
|
Then on switch 4, I'm going to
|
|
0:17:00
|
We now received the query...
|
|
0:17:03
|
from router 5 about the particular prefix,
|
|
0:17:08
|
and notice that we're not forwarding
|
|
0:17:13
|
So, we received it,
|
|
0:17:14
|
but we're not sendin. We immediately send a reply saying,
|
|
0:17:22
|
Because when I say Show IP Route 150.10.10.0/24,
|
|
0:17:32
|
I don't actually have a route.
|
|
0:17:35
|
So again, it's both saving space in the routing table,
|
|
0:17:38
|
and optimizing the reconvergence rocess for EIGRP.
|
|
0:17:47
|
Now, let's say for the loopback of switch 2.
|
|
0:17:53
|
We always want that particular traffic
|
|
0:17:55
|
to route in the link that is coming from router 4.
|
|
0:18:01
|
So, if we're going to switch 2's loopback,
|
|
0:18:04
|
If we're going to switch 4's loopback,
|
|
0:18:07
|
It could be coming on this link or this link.
|
|
0:18:13
|
This is where our leak map could be
|
|
0:18:18
|
So, on router 5, on the link to router 4,
|
|
0:18:24
|
when we generate the summary,
|
|
0:18:25
|
we're going to specifiy a leak map that is a route
|
|
0:18:33
|
So, we'll have the prefix list that
|
|
0:18:40
|
that is matching 150.10.8.0/24.
|
|
0:18:46
|
I then have a route map...
|
|
0:18:49
|
that is the leak map...
|
|
0:18:51
|
that says, "Batch IP address prefix list...
|
|
0:18:56
|
switch 2's loopback zero."
|
|
0:19:01
|
Then at the link level,
|
|
0:19:06
|
under the summary address command,
|
|
0:19:13
|
So now, if we look at router 4's routing table,
|
|
0:19:17
|
we see that we do not have a route
|
|
0:19:23
|
So, we don't have the exact subnet,
|
|
0:19:26
|
but we now should have the exact subnet for the...
|
|
0:19:31
|
loopback of switch 2.
|
|
0:19:33
|
When we look at the...
|
|
0:19:38
|
We look for any route...
|
|
0:19:41
|
for switch 4's loopback,
|
|
0:19:44
|
that's matching the aggregate.
|
|
0:19:46
|
So, the difference is that one of them is matching the
|
|
0:19:53
|
So, all traffic that is going to that destination...
|
|
0:19:56
|
will then router to router 4.
|
|
0:19:58
|
Because everyone is gonna choose
|
|
0:20:03
|
For the other routes to...
|
|
0:20:07
|
switch 4's loopback,
|
|
0:20:09
|
they're gonna look at what is the
|
|
0:20:15
|
But for this one, it basically doesn't matter what the
|
|
0:20:21
|
So, let's look at this from
|
|
0:20:25
|
What we should see is that if
|
|
0:20:29
|
these packets have to go to 4 first.
|
|
0:20:36
|
If we trace 150.10.8.8,
|
|
0:20:40
|
we see those packets do transit to router 4.
|
|
0:20:44
|
If we look at the ones going
|
|
0:20:47
|
Those don't necessarily
|
|
0:20:51
|
because there's multiple longer...
|
|
0:20:56
|
that router 5 is advertising for both of them.
|
|
0:20:59
|
Now additionally, we can use the...
|
|
0:21:04
|
the summary address command
|
|
0:21:08
|
So, we could aggregate all
|
|
0:21:12
|
The only disadvantage of doing this...
|
|
0:21:16
|
is that it's going to suppress all of the subnets,
|
|
0:21:20
|
and everything is a subnet of /0.
|
|
0:21:24
|
So, on router 5, if we were to remove...
|
|
0:21:27
|
the previous summary on
|
|
0:21:36
|
and we'll replace it with a summary...
|
|
0:21:39
|
that goes just to 0.0.0.0,
|
|
0:21:49
|
we'll see that this is a valid configuration,
|
|
0:21:53
|
but when we look at a
|
|
0:22:03
|
so, you can see, by
|
|
0:22:07
|
it caused a withdrawal
|
|
0:22:10
|
So, the rest of the neighbors had to
|
|
0:22:15
|
So now, if I Show IP Route EIGRP,
|
|
0:22:19
|
we'll see that all the routes that
|
|
0:22:24
|
they're now summarized to the single /0.
|
|
0:22:30
|
So, this would then include the...
|
|
0:22:40
|
this Ethernet of router 5.
|
|
0:22:42
|
The Ethernet between 5 and switch 2,
|
|
0:22:45
|
switch 2's VLAN 8, the VLAN 10,
|
|
0:22:50
|
So, all of these routes are to
|
|
0:22:56
|
Which isn't necessarily bad, it depends on
|
|
0:23:00
|
but as we know anytime we do
|
|
0:23:05
|
we lose specific reachability information
|
|
0:23:09
|
But whether we care, do we wanna route to
|
|
0:23:17
|
Okay, if it doesn't matter, then, we
|
|
0:23:20
|
But likewise,
|
|
0:23:23
|
since we do have the option for the leak map,
|
|
0:23:25
|
we can still control...
|
|
0:23:28
|
on a per-subnet basis where
|
|
0:23:32
|
So, on router 5, I could do the
|
|
0:23:39
|
that is matching that specific subnet of the...
|
|
0:23:43
|
of switch 4's loopback.
|
|
0:23:44
|
So, if I take that summary address
|
|
0:23:48
|
which match in the leak map."
|
|
0:23:52
|
Router 4 should now have an
|
|
0:24:01
|
which again that means that all of the
|
|
0:24:05
|
router 4.
|
|
0:24:07
|
So really, summarization has
|
|
0:24:12
|
It's used to cut down on the
|
|
0:24:16
|
by taking multiple routes and then combining
|
|
0:24:20
|
but also by selectively advertising
|
|
0:24:25
|
we end up in a traffic engineering design,
|
|
0:24:29
|
where the routers are always preferring
|
|
0:24:34
|
So, we'll see, this is especially useful for BGP.
|
|
0:24:37
|
When we get into the aggregation with the summary
|
|
0:24:43
|
there's a lot of flexibility as to how we
|
|
0:24:47
|
Now again, we'll see in router 5
|
|
0:24:54
|
that the aggregate that we are generating...
|
|
0:24:58
|
So, in this case, the aggregate is 0.0.0.0/0,
|
|
0:25:02
|
our longest match for this is
|
|
0:25:08
|
This now means that router 5 would
|
|
0:25:13
|
to any other destinations in the network.
|
|
0:25:18
|
Because now, the discard route, the route
|
|
0:25:23
|
So, let's say we were to go to...
|
|
0:25:26
|
switch 2, and advertise
|
|
0:25:31
|
Okay, we have let's say, 8.8.8.8..
|
|
0:25:35
|
And we want router 5 to be able to reach this
|
|
0:25:39
|
by using a default route.
|
|
0:25:41
|
We want a default route that
|
|
0:25:44
|
So, for whatever destinations are behind it.
|
|
0:25:50
|
But with this summary installed in the table,
|
|
0:25:56
|
that's not gonna happen.
|
|
0:25:58
|
So, whether the summary is a dynamic,
|
|
0:26:01
|
or excuse me, whether the default
|
|
0:26:05
|
or whether it is statically configured,
|
|
0:26:09
|
we have to take into account when this
|
|
0:26:16
|
So let's say on switch 2...
|
|
0:26:18
|
that we have this new address.
|
|
0:26:20
|
Loopback 8 with an address 8.8.8.8.
|
|
0:26:29
|
And on the link to router 5, we are
|
|
0:26:35
|
So, let's say IP Summary Address EIGRP 1...
|
|
0:26:38
|
is all zeros.
|
|
0:26:44
|
When we look at router 5,
|
|
0:26:47
|
and we Show IP Route Include 0.0.0.0,
|
|
0:26:51
|
We'll see that we are not able to install the
|
|
0:27:00
|
because the administrative
|
|
0:27:04
|
is lower than the dynamically learned one.
|
|
0:27:07
|
This is white at the link level,
|
|
0:27:10
|
we have the option to change
|
|
0:27:15
|
So, if I were to go to serial 0/0/0,
|
|
0:27:20
|
and say that the distance of this
|
|
0:27:26
|
So, I'll say it's 91...
|
|
0:27:29
|
on both of my links.
|
|
0:27:33
|
Then, when look at the routing table,
|
|
0:27:36
|
we see that now, we can install
|
|
0:27:44
|
So, we're essentially doing a
|
|
0:27:48
|
That if we are learning the
|
|
0:27:53
|
we will install that in place of the null route.
|
|
0:27:57
|
But if switch to withdraws its
|
|
0:28:05
|
then, router 5...
|
|
0:28:10
|
will start to drop traffic towards that.
|
|
0:28:15
|
Okay, we'll see, once this converges,
|
|
0:28:20
|
So, whether you want the null
|
|
0:28:23
|
whether you want to use a shorter match
|
|
0:28:26
|
to reach a destination that is
|
|
0:28:32
|
Because otherwise, the longest
|
|
0:28:36
|
is gonna be the null route.
|
