|
0:00:13
|
In our next section here for EIGRP,
|
|
0:00:16
|
we're gonna look at how to use the
|
|
0:00:20
|
to cut down on the query domain
|
|
0:00:22
|
in addition to using the previous
|
|
0:00:27
|
Now again, with the summarization,
|
|
0:00:30
|
the reason that the query domain is limited
|
|
0:00:33
|
is that when EIGRP router
|
|
0:00:37
|
sends a summary route to
|
|
0:00:41
|
wher previously, we looked at a case
|
|
0:00:48
|
which was actually made up
|
|
0:00:53
|
10.0.1.0, 10.0.2.0, and 10.0.3.0/24.
|
|
0:01:01
|
When this summary is advertised
|
|
0:01:06
|
and in the future, one of the subnets goes down.
|
|
0:01:09
|
So, router 2 loses connectivity to 10.0.2.0/24,
|
|
0:01:15
|
a query message is gonna go
|
|
0:01:18
|
asking them do you have an alternate
|
|
0:01:22
|
Now, when router 3 and 5 receives
|
|
0:01:26
|
it is going to be for the specific prefix
|
|
0:01:30
|
that router 2 has lost, which is the 10.0.2.0/24.
|
|
0:01:36
|
Since router 3 and router 5 do not have
|
|
0:01:41
|
they only have the less specific match of the /22,
|
|
0:01:44
|
they immediately send the query reply back...
|
|
0:01:49
|
saying that "I have no other possible
|
|
0:01:54
|
The key point being here is that when reconvergence happens,
|
|
0:02:02
|
it must send a query to all
|
|
0:02:06
|
and wait for the reply to come
|
|
0:02:10
|
Now, with the summarization,
|
|
0:02:13
|
the idea behind this is that if
|
|
0:02:17
|
has reachability to these other
|
|
0:02:24
|
then there's no reason that router 2 should
|
|
0:02:30
|
Now, the same would be true
|
|
0:02:32
|
of the stub routers in the topology that have
|
|
0:02:39
|
And in our particular case,
|
|
0:02:43
|
this would be the case for
|
|
0:02:50
|
So, switch 3 and switch 4, they are at
|
|
0:02:54
|
where beyond them, there are no
|
|
0:02:58
|
This means that whatever prefixes that
|
|
0:03:03
|
like the VLAN 9 interface,
|
|
0:03:12
|
the VLAN 10 and the loopback of switch 4,
|
|
0:03:16
|
those of the only possible prefixes that
|
|
0:03:22
|
Now, in the case where there is a failure
|
|
0:03:26
|
the query messages that are not
|
|
0:03:30
|
will have to be sent to every single
|
|
0:03:34
|
So, if the network is 10,000 routers, it means that all
|
|
0:03:41
|
So, this is why summarization is so important.
|
|
0:03:44
|
Now, for stub routers,
|
|
0:03:48
|
likewise, it does not make sense for
|
|
0:03:52
|
about destinations they could not possibly
|
|
0:03:59
|
So, let's say for example that router 4...
|
|
0:04:02
|
is learning networks in from BB3.
|
|
0:04:05
|
So, these are learned from RIP and
|
|
0:04:13
|
This is the only possible way...
|
|
0:04:16
|
that these RIP routes from BB3 could be accessed.
|
|
0:04:21
|
So, switch 3, if it wants to route traffic there,
|
|
0:04:23
|
it has no option but eventually to send traffic to 4.
|
|
0:04:26
|
Llikewise from switch 4's perspective.
|
|
0:04:30
|
Now, the problem we'll run into though
|
|
0:04:33
|
is that any time one of these
|
|
0:04:38
|
router 4 will generate a query message
|
|
0:04:42
|
do you have an alternate route to this path?
|
|
0:04:45
|
So, in this case, if router 4 loses one of its routes,
|
|
0:04:48
|
it sends a query message to router 1, to router 6,
|
|
0:04:53
|
6 sends it to switch 1, switch 1 sends it to switch 3.
|
|
0:04:58
|
Eventually, switch 3 will send the reply,
|
|
0:05:01
|
and the replies will go back on the
|
|
0:05:07
|
but just by looking at the physical topology here,
|
|
0:05:11
|
that should not be receiving
|
|
0:05:15
|
Specifically, in our case, these would
|
|
0:05:18
|
who have no other routing
|
|
0:05:23
|
And this is where the EIGRP stub
|
|
0:05:27
|
So, the idea behind the stub
|
|
0:05:31
|
is that when we form the adjacencies
|
|
0:05:35
|
we advertise yourself as an
|
|
0:05:39
|
This will prevent those upstream neighbors
|
|
0:05:45
|
for prefixes that are coming from
|
|
0:05:50
|
So, in this case, if switch 3 was
|
|
0:05:55
|
when switch 1 receives the
|
|
0:06:01
|
instead of forwarding this on the switch 3,
|
|
0:06:07
|
This is because during the
|
|
0:06:10
|
switch 3 is going to tell switch 1,
|
|
0:06:14
|
Now, the configuration for the
|
|
0:06:17
|
It's simply one command under the
|
|
0:06:21
|
We'll also see, there's different
|
|
0:06:24
|
what type of prefixes the
|
|
0:06:29
|
So, let's look at this on this on the topology
|
|
0:06:33
|
for what happens before and after
|
|
0:06:40
|
Now, on switch 3, let's look at the Debug EIGRP
|
|
0:06:49
|
So, this is gonna be for the
|
|
0:06:53
|
Then, let's say that some failure
|
|
0:06:56
|
Let's say that it is on a router 4's loopback.
|
|
0:07:00
|
So, router 4's loopback goes down,
|
|
0:07:03
|
this is not cause the query
|
|
0:07:06
|
which eventually gets down to switch 3.
|
|
0:07:10
|
Switch 3 received the query message in from
|
|
0:07:16
|
Basically says, "I don't have any other path to
|
|
0:07:21
|
So, it sends the reply back to switch 1 saying,
|
|
0:07:26
|
Eventually, this gets back to router 4,
|
|
0:07:29
|
then, everyone can delete this
|
|
0:07:34
|
But the disadvantage of this design is that we know
|
|
0:07:41
|
So, there's no reason to be getting
|
|
0:07:46
|
To fix this,
|
|
0:07:48
|
under the process of switch 1,
|
|
0:07:52
|
we will advertise ourselves as
|
|
0:07:59
|
Once we do this,
|
|
0:08:01
|
and we look at from the remote neighbor,
|
|
0:08:03
|
switch 1 is the upstream neighbor here.
|
|
0:08:05
|
If we look at the Show IP
|
|
0:08:11
|
we see that switch 3 who has
|
|
0:08:18
|
is advertising...
|
|
0:08:20
|
itself as a stub router.
|
|
0:08:24
|
Additionally, it is advertising its connected routes
|
|
0:08:31
|
So, this means that if there are ther routes
|
|
0:08:39
|
from switch 3's perspective, these routes
|
|
0:08:44
|
pass switch 3.
|
|
0:08:47
|
So typically, in the stub router design,
|
|
0:08:51
|
there should not be any other
|
|
0:08:54
|
So, if we were to have the case were switch 3
|
|
0:09:00
|
let's say, switch 5,
|
|
0:09:01
|
and EIGRP routes are coming in,
|
|
0:09:05
|
when switch 3 declares itself as a stub router,
|
|
0:09:09
|
it means that these messages
|
|
0:09:12
|
they will not be forwarded out that link.
|
|
0:09:16
|
So typically, an EIGRP stub router
|
|
0:09:21
|
Now, we'll see, there are some
|
|
0:09:25
|
We can tell the stub router to
|
|
0:09:29
|
It really depends on where in
|
|
0:09:34
|
and if there is someone else behind us
|
|
0:09:38
|
But with the default options,
|
|
0:09:41
|
if we look at the running configuration switch 3,
|
|
0:09:45
|
Show Run Begin Router EIGRP,
|
|
0:09:50
|
the arguments for EIGRP stub
|
|
0:09:54
|
So, it means that any links that I have locally
|
|
0:09:57
|
being originated into the topology,
|
|
0:10:00
|
Plus if I were to generate a summary route.
|
|
0:10:05
|
If we look at switch 1, and
|
|
0:10:11
|
it's not gonna change anything
|
|
0:10:15
|
because we're still learning
|
|
0:10:20
|
that is attached to switch 3, we're still
|
|
0:10:27
|
it just means that switch 3
|
|
0:10:32
|
Now, once switch 1, if we were to look at
|
|
0:10:41
|
and likewise do the same thing on
|
|
0:10:45
|
we're still debugging the queries and replies.
|
|
0:10:48
|
And now, let's say on switch...
|
|
0:10:53
|
we lose connectivity to our loopback.
|
|
0:10:55
|
So, this withdraws this from the topology.
|
|
0:10:59
|
It generates a query message,
|
|
0:11:02
|
and we should see that from
|
|
0:11:12
|
we are not receiving a query message.
|
|
0:11:16
|
Now, this output here says that switch 3
|
|
0:11:20
|
because likewise it lost the route
|
|
0:11:24
|
but it's not receiving a query
|
|
0:11:28
|
So, on switch 1, when we look at... First,
|
|
0:11:34
|
So, router 6 is asking...
|
|
0:11:36
|
switch 1 do you have an alternate
|
|
0:11:41
|
Switch 1 normally would then send us
|
|
0:11:46
|
but in our case, when we look at who
|
|
0:11:52
|
its going out to VLAN 67. So, it's
|
|
0:11:57
|
It's going towards router 3.
|
|
0:12:01
|
Then it would normally be going
|
|
0:12:07
|
but we'll see, this one is actually dropped.
|
|
0:12:10
|
So, we prepare the query message
|
|
0:12:16
|
but then, the message is not actually sent.
|
|
0:12:23
|
Now, we see that we are receiving
|
|
0:12:27
|
we reply back to them saying, "I do not have an
|
|
0:12:34
|
So, the feature is essentially doing two things here.
|
|
0:12:39
|
It's reducing the query domain.
|
|
0:12:43
|
And it's also used to prevent a
|
|
0:12:48
|
So, it's a type routing filter.
|
|
0:12:51
|
Now, we can use this...
|
|
0:12:53
|
to reduce the query domain by more than one hop,
|
|
0:12:57
|
because essentially what we
|
|
0:13:01
|
we're only cutting off...
|
|
0:13:03
|
just one router out of the network, which is switch 3.
|
|
0:13:07
|
So, let's say we wanna do this on...
|
|
0:13:10
|
switch 2.
|
|
0:13:13
|
Now I also have some previous
|
|
0:13:17
|
that was on switch 2 and router 5, we're gonna
|
|
0:13:23
|
So, let's go to switch 2,
|
|
0:13:26
|
and at our interface level,
|
|
0:13:31
|
switch 2 is not doing any summarization,
|
|
0:13:35
|
and let's see what router 5 is doing.
|
|
0:13:39
|
5 is advertising a...
|
|
0:13:42
|
default route...
|
|
0:13:47
|
out the frame-relay interface and out
|
|
0:13:54
|
So, I'm gonna remove those, we're just
|
|
0:14:01
|
So, at this point, from router 5's perspective,
|
|
0:14:04
|
we should be able to reach...
|
|
0:14:06
|
the loopback of switch 2.
|
|
0:14:12
|
Because that neighbor is directly connected.
|
|
0:14:13
|
Then, we should also be able to transit
|
|
0:14:18
|
which is 150.10.10.10.
|
|
0:14:22
|
So, we can see now, down in the bottom
|
|
0:14:26
|
there's no problems in reachability.
|
|
0:14:28
|
So, router 5 can reach both of these neighbors.
|
|
0:14:33
|
Next, we'll configure switch 2 as a stub router.
|
|
0:14:39
|
So, under EIGRP 1, we'll say EIGRP Stub.
|
|
0:14:44
|
Again, the default argument for this
|
|
0:14:48
|
are the EIGRP stub connected summary.
|
|
0:14:52
|
This means that whatever my routes
|
|
0:14:58
|
plus any summaries that I'm locally generating,
|
|
0:15:01
|
those are the prefixes that can be
|
|
0:15:07
|
This would then imply
|
|
0:15:10
|
that the inbound updates we're receiving
|
|
0:15:14
|
from either router 5 or from switch 4
|
|
0:15:20
|
So, if we'd look at switch 4 and look at
|
|
0:15:26
|
we see that we're essentially losing reachability
|
|
0:15:33
|
Now, this isn't necessarily bad as long as we
|
|
0:15:39
|
with other less specific routes.
|
|
0:15:44
|
Now, since switch 2 says under the process
|
|
0:15:48
|
that I'm allowed to advertise my
|
|
0:15:52
|
it would then be valid for...
|
|
0:15:55
|
switch 2 to go to its port channel
|
|
0:16:00
|
and say IP Summary Address
|
|
0:16:04
|
I'll just give you a default route.
|
|
0:16:09
|
So, since switch 2...
|
|
0:16:11
|
is always in the transit path
|
|
0:16:14
|
for switch 4 to get anywhere.
|
|
0:16:17
|
In reality, it doesn't need to send it
|
|
0:16:24
|
Then likewise, if router four loses
|
|
0:16:29
|
a query message is not to go down
|
|
0:16:36
|
We'll see, the issue was now even though
|
|
0:16:41
|
out to the rest of the domain if we
|
|
0:16:46
|
we Show IP Route EIGRP.
|
|
0:16:51
|
We'll see that on the way back, no one is
|
|
0:16:57
|
So we'll see, switch 2's code version, it may
|
|
0:17:03
|
this is the Catalyst-IOS.
|
|
0:17:06
|
Let's see, under the EIGRP process,
|
|
0:17:13
|
Connected summary is the default,
|
|
0:17:16
|
where we should see in the newer
|
|
0:17:23
|
so 12.4T...
|
|
0:17:25
|
Under the routing process, if we say a
|
|
0:17:33
|
This has the option for a leak map
|
|
0:17:37
|
that is similar to the leak map we
|
|
0:17:41
|
So, in this particular to topology.
|
|
0:17:47
|
let's say this is router 7,
|
|
0:17:49
|
it would be able to take the updates
|
|
0:17:53
|
and then leak them up to router 5.
|
|
0:17:57
|
Likewise then, the routes are coming from
|
|
0:18:03
|
The other option would be to do
|
|
0:18:06
|
Like if I said on...
|
|
0:18:10
|
switch...
|
|
0:18:12
|
2..
|
|
0:18:15
|
that I have static routes to
|
|
0:18:25
|
and this is via the...
|
|
0:18:29
|
port channel interface to switch 4.
|
|
0:18:33
|
Under EIGRP process now,
|
|
0:18:37
|
I could put a network statement
|
|
0:18:42
|
and say EIGRP Stub Connected Static,
|
|
0:18:48
|
which should then mean...
|
|
0:18:51
|
this route would be able to
|
|
0:18:56
|
And if we Show IP Route EIGRP.
|
|
0:19:04
|
So, I wanna see, do I know the route for...
|
|
0:19:09
|
150.10.10.0.
|
|
0:19:13
|
Okay, so right now, it's not in the table.
|
|
0:19:15
|
On some versions, it may not... Like I said, this is an
|
|
0:19:22
|
The routers do support the case where
|
|
0:19:26
|
that matches a static route.
|
|
0:19:29
|
It's kind of like doing redistribute static,
|
|
0:19:32
|
but it advertises the prefixes in internal
|
|
0:19:40
|
So, in this case, the static route wasn't picked up,
|
|
0:19:42
|
which means that I would have to...
|
|
0:19:45
|
say "Instead of the network statement..."
|
|
0:19:56
|
So, No Network for the static route.
|
|
0:19:58
|
Instead, I'll say Redistribute Static.
|
|
0:20:01
|
And we'll give it any arbitrary metric.
|
|
0:20:08
|
So now, router 5 is able to learn the external route
|
|
0:20:12
|
that has been leaked by the stub router.
|
|
0:20:16
|
Then, we will still have the problem
|
|
0:20:20
|
that...
|
|
0:20:24
|
switch 4 doesn't have a route to router 5 now.
|
|
0:20:28
|
So, we could do some workaround like
|
|
0:20:41
|
So now, we just have static reachability
|
|
0:20:48
|
So now, if router 5 were to ping 150.10.10.10,
|
|
0:20:54
|
we see that we do have reachability.
|
|
0:20:57
|
But the difference now is that if we
|
|
0:21:02
|
switch 2 is advertising itself as a stub peer,
|
|
0:21:07
|
which means that if any network
|
|
0:21:14
|
so the link between router 1 and 3,
|
|
0:21:18
|
when router 5 receives these query messages in,
|
|
0:21:23
|
they're not gonna go to switch 2
|
|
0:21:31
|
Now the case for this is commonly
|
|
0:21:35
|
is what is within the scope of DM VPN...
|
|
0:21:38
|
the Dynamic Multipoint VPN,
|
|
0:21:40
|
where we a hub site that is terminating
|
|
0:21:48
|
that goes down to the spokes of the network
|
|
0:21:53
|
for the purpose of running IP Sec over GRE.
|
|
0:22:00
|
And inside...
|
|
0:22:02
|
these GRE tunnels,
|
|
0:22:06
|
we're using EIGRP as our routing protocol.
|
|
0:22:11
|
So, typically, the spokes would define
|
|
0:22:20
|
Then additionally, they would
|
|
0:22:25
|
for whatever subnets are behind them.
|
|
0:22:29
|
So then, if one of the subnets goes down,
|
|
0:22:31
|
a query message is not sent up to the hub,
|
|
0:22:35
|
and likewise, if there is a query generated behind
|
|
0:22:42
|
So, the key point being here...
|
|
0:22:44
|
that EIGRP scalability is based
|
|
0:22:49
|
that do we have the backup
|
|
0:22:53
|
And if we do not have a backup routes,
|
|
0:22:56
|
what is the minimum number of routers we
|
|
0:23:01
|
in order to potentially find an alternate
|
|
0:23:07
|
So, we don't want to ask routers that we
|
|
0:23:11
|
because it's just a waste in the cycles,
|