Now before we move back into the lab let's touch on
another reason to use summarization.
Well,
summarization is very useful in limiting the number of
networks that are required to be known by the different
devices throughout the network.
With EIGRP it is also very helpful because it limits the
reach of query messages through a network.
It does this in a couple of different ways.
First,
it will limit the amount of individual networks that need to be
processed by the different devices in the network.
For example,
the core devices don't need to be aware of specific access devices going down.
By using a summary from the distribution to the core
all the core will see is a summary.
The distribution device would handle any issues and
limit the exposure into the core.
And second,
when a query is sent it is sent per route and with the
original prefix length information.
So even if a device receives a query from a device that it has
previously received a summary from it will not have that specific
route entry in its topology table.
It will only have a summary, which will not be an exact match,
and because of this it will return a reply with no available other paths.
Now let's move on and talk about EIGRP stub routing.
This is a feature that has been developed mainly for situations
where a hub and spoke network design are being used.
This is often seen in networks with branches and a connecting
WAN that is laid out in a hub and spoke.
In these cases, a stub feature can provide two main advantages.
First, it communicates back towards the distribution router to not send queries.
Since these branches or spokes are intended to be used for only
traffic coming to and from their networks,
and their reachability doesn't change, there is no reason to send queries,
and second,
configuring a device as an EIGRP stub will prevent it
from becoming a transit device, should an upstream failure occur.
For this we are going to move back into the lab to show it in action.
So let's begin this demo by taking a look at the lab topology again.
In this case, we have changed one thing in the topology.
We have dual-homed the Access2 device,
so it's connected to both distribution 1 and distribution 2,
and this is done for 1 purpose.
One is to try to show what can happen if you have
dual-homing configuration like this, and there is an upstream failure.
The other thing that I have altered in the configuration on the
devices themselves is I have disabled the summaries,
the default summaries from both the distribution routers down to Access2.
So the Access2 router currently sees everything the distribution routers would,
and I've only done this to sort of give you a better view into what
information it's seeing and we'll see how not configuring the stub
feature can affect the path that's chosen,
and sometimes it chooses a path that you don't really want it to take.
So if we look at the lab again here,
and we log in to Access2 we can see the routing table on Access2,
it's the whole table that we saw,
pretty much no other router has this whole thing
because I left the other summaries up,
but for this example it was important to sort of disable the
summaries and just take a look at what we're seeing here.
Right at the moment,
if Access2 wants to get to the 2 access routers that connect directly off
--- or previously connected only off of distribution 2,
then he can just go directly through distribution n2,
and this is shown in the 128 --- these networks right here,
128.
This is the LAN router for the Access128 router.
This is the LAN for Access129 access router,
and these go directly to distribution 2 directly.
It doesn't go through distribution 1 anymore because
of this dual-home configuration.
Now if we look at Access1 I didn't take that summary away,
so his routing table is still rather simple,
and if we look at distribution 1 device we'll see the 128.
Now currently to prepend this the topology that we're looking at,
and the configuration it is, all of the links are considered exactly the same.
The costs are exactly the same, and the link speeds are exactly the same.
So that being considered, let's take a look at this.
Now the distribution 1 device has a route to the LAN off of Access128.
But which way does it go?
It's saying the best route from him right now is to go to 15.6.
Well who's 15.6?
What device does he have in that network or what
interface does he have in that network?
He is on this gigabit 0/4 interface, and 0/4 is connected to Access2.
So right now instead of going up into the core,
where he would prefer to go,
he's using the Access2 router as a transit to some networks because that's the
best EIGRP path because all the links are the same speed.
Now obviously in a real environment most of the upper stream
links you would think would have faster links,
but it's really important to sort of understand how EIGRP thinks.
It's just looking for the lowest cost metric.
It doesn't care what your topology is or how you want traffic to flow,
so you have to make sure to look into these little things.
So the same thing would happen.
So if we take the Access1 and did a trace from Access1 to one
of the access routers on the other side,
you'll see that he bounces the distribution 1,
and then he goes back down to the other access router,
to the other distribution router, and then finally to Access129.
Now, obviously,
this is not the preferred behavior because you don't want the
access routers to be used as transit routers,
and one of the ways to limit this,
and actually one of the easiest ways to limit this is you
configure a device as an EIGRP stub, and as I noted in the slides,
this has two main effects.
One is that it will disable queries from coming down
from the distribution device down,
so the distribution device will see that an access
router is configured as a stub, and it will mark in its tables,
okay, if somebody sends me a query, so in this case,
if the core sends him any queries they're all going to stop at him and he's
not going to send any queries down to the access router,
so there's no wait for replies back from the access routers.
It all stops at the distribution router.
So if he doesn't have an additional route it moves back
to the core and with a reply it says, I don't know how to get there.
So how would we do that?
For Cisco it's rather easy.
It's one command.
We would go on the access device, in this case it's Access2,
and you're configuring it as a stub.
Now while this isn't a configuration course,
I will note that if you're using it on Cisco equipment this command
only goes on the actual stubbed router or routers,
depending on your network.
It does not go on the distribution.
It's only on the stub,
and the stub will advertise himself as a stub to the distribution,
and we're going to take a look at that in a minute as well.
Now by doing that it bounces its two neighborships.
It has a neighborship to distribution 1 and a neighborship to distribution 2.
Now both of those routers know that it's a stub,
and they will make their routing decisions based on that.
So if we move back to distribution 1 and look at his routing table again,
and keep those the 128.0 /24 and 129.0 /24 networks in mind again,
we'll remember that since I left all the original summaries
intact we're going to lose those individual networks because
they were going through Access2,
and we're going to receive only those summaries now.
So that summary going to those two routers,
this is the summary that we got from the core that we previously configured,
and these are the two paths that distribution 1 will use in order to
get to the access LANs for Access128 and Access129.
And again, to verify this we can run a trace from Access1.
In this case, he again,
goes to distribution 1 because that's his only connection point,
but here's where the path changes.
Instead of going back down to Access2 now it goes up to the Core,
it goes to distribution 2, and now it goes out to Access129,
which is our wanted behavior.
We don't want any of these access devices to become transit.
Now, as I noted,
if we were in a more normal environment and the upstream links were faster,
then EIGRP wouldn't automatically be routing it,
sort of like we saw in access, the distribution routers before,
and the access router.
It would automatically be probably sending it up towards the
Core just based on default configuration.
However,
the problem comes is even if the links are slow between the
distribution routers and the access routers,
if the distribution routers had an upstream failure,
so right now they're dual-homed to both the Core routers,
so he would have to lose both of those links that go up.
If that happened, well he still has neighborships down to the access,
and the access devices still have connectivity.
In this case, Access2 still has connectivity over to distribution 2.
So what would happen if distribution 1 lost his two links to the core,
he would send queries back down,
assuming stub wasn't configured to the access devices,
and Access2 would go, well hold on,
I have reachability over to distribution 2 on his networks,
and without doing anything,
which is sort of how EIGRP is normally supposed to work,
a new route would be found for all of the distribution 1
destinations through Access2 with those failures,
and then you sort of inadvertently get that weird behavior.
So that's something to look into if you get sort of weird --- if
you're getting traffic bouncing back through access routers or out
places that are supposed to be stubbed out,
then you really need to look into configuring some
type of either filtering or stub, and stub is the easy one with EIGRP.
So with that, that's all I wanted to show for this current demo,
and we're going to move on into the next section where we talk about the significance of EIGRP router IDs.