So now let's move back into the lab and see --- first let's take a
look at the routing table on the core devices,
and if we take a look here we'll see that he has individualized
knowledge of all of the LAN networks at the access layer,
which in this case this is Access1, Access2,
Access128, and Access129,
as well as the --- WAN networks between
distribution 1 and its few access routers,
and the WAN links between distribution 2 and it's access routers.
But there's no real reason that any of the core
devices need to be aware of these.
You'll see that Core2 has a similar view.
So in order to correct this what we can do is we can go onto the
distribution routers and we can take a look at the interfaces that
connect from the distribution routers to the core.
In this case,
on distribution 1 he has his gigabit 0/1 --- and gigabit 0/2 interfaces,
so if we go to 0/1 what we're summarizing is that 192.168 .0 .0 /20.
So 192.168 .0 .0 and 20.
Let's do 40, and we're going to put the same summary on 2,
which goes up to Core2.
And on distribution 2 we want to do a similar thing.
Look at the interfaces, which are still gigabit 0/1 and 0/2.
In this case, he wants to advertise the 128 network /20 to both Core1 and Core2.
Then when we do this we move back to the core and relook at his routing table.
We'll see that in favor of showing all those individual routes,
now he just shows this one,
which is the route that goes from him directly to the
distribution 1 device because it has a shorter path.
If you wanted this to have equal cost you could sort of
change the reachability a little bit,
but in this case there's one route that goes from
Core1 to the distribution 1 router, which is this one,
and then there's another summary for the 128 network,
which goes directly from him to the distribution 2 network.
So you can see from that that it's routing table is
considerably condensed from where it was.
It doesn't need to have individualized knowledge.
If those networks go up and down he doesn't have to process anything.
The summary stays static.
The same is going to be true if we look at the routing table on Core2.
On Core2 he also has a summary route that goes directly from Core2 to
distribution 1 and directly from Core2 to distribution 2,
and if we want to verify this we can also go back to the access
routers and just verify our reachability again.
And verify that that summary didn't touch these.
These guys are still using that default route.
Now is there any other place that we may be able to get away with a summary?
Let's move back to the topology for a second.
Now if we look at this do you think there's any other places
here that we could configure summarization in order to reduce
the size of the routing tables?
We already configured a summary from the distribution routers to the access
routers and from the distribution routers to the core routers,
but we haven't configured any summarization that faces the distribution router,
so the distribution routers, at this point,
still know about all the networks,
but there's no real reason for that because if we look at the IP
information we can see that distribution 1 will always take the same
two paths to the 192.168 .128 .0 /17 network because the /17 is
everybody that's on the distribution 2 side,
and the reverse is true.
Distribution 2 will only take the same two paths to go
to the 192.168 .0 .0 /17 network.
So there's no real need for the distribution routers to
know about the reachability information of the other
distribution routers access devices.
If we move back in the lab for a second and take a look at
the distribution router we'll see that distribution 1 is
aware of its own access routers, which is fine.
These are the LANs off of Access1 and Access2,
and it sees the summary that was sent from distribution 2
into the core via 2 equal cross paths, but he also shows these networks.
And what are these networks?
These two routes are the WAN links that go between the
core and the distribution 2 device,
but is distribution 1 really going to take a
different path to either one of these,
or can we further summarize this 128 network a little bit higher up in
boundary in order to try to squish down the sides of the routing table
on distribution 1 a little bit more,
and let's move to distribution 2 for a second because I can show
that the opposite is true on distribution 2.
See he is aware of the fifth or between the core and distribution 1.
So I think there's one more place we could put a summary,
and that's from the core down.
When we move the topology for a second we can show here is that all
of the networks that are connected from the core down to distribution
1 are in the 192.168 .0 .0 /17 network,
and all of the networks that are from the core down to
distribution 2 are in the 192.168 .128 .0 /17 network.
So if we move back to the lab for a second we can move the boundary
from a 192.168 .0 .0 /20 for distribution 1 to a /17,
and we can move the boundary on the distribution2
side from the 128.0 /20 to the /17, but we do that at the core.
We'll move back to the core for a second.
Now the two interfaces that connect Core1 to the
distribution are its 2 and 3 interfaces.
So if we go onto its 2 and configure another summary,
in this case, and this is Core1 connecting to distribution 1.
Now we have to make sure to advertise the right summary here because,
in this case, since this is connecting to this 1,
the distribution 1 router and all the networks under it,
we need to be summarizing the networks from those
that connect via distribution 2.
In this case,
we're advertising to distribution 1 the 192.168 .128 .0 /17 network,
not the 0.0 /17 because those are the ones that are
connected to distribution 1 already.
So we connect --- so we configure the 128 and then the 17.
Now the same is not true for its gigabit 0/3 interface.
This is the one that --- is connected to distribution 2.
In this case,
we're going to be advertising the networks that
connect off and towards distribution 1.
So this is the 0.0 /17.
Now if we repeat that,
the opposite of that on the Core2 device is gigabit 0/2 interface
is configured to connect to distribution 2.
So since he goes to distribution 2 you're going to put 0.0 first.
If you go to 3 you're connecting to distribution 1.
So with that complete let's look at the routing table of distribution 1.
So now he has a few additional routes removed,
and as you can see, he has the 17, and all of those WAN links,
and the other /20 summary are all wrapped into this 1 network entry.
And you can see they're equal cost.
So from distribution 1 to that network for all those
networks can go to Core1 or Core2 equally,
and his routing table is squeezed about as much as we're going to get it.
You know,
if we moved distribution 2 we should see a similar effect that's
basically a mirror of that for the 17 network.
As for the 0.0 it can pick is configured here,
and again, 2 equal crossed paths to Core1 and Core2.
So again, to finish this up,
let's verify that Access1 still has reachability to
the other side of the network,
just to make sure we didn't break anything in the middle here.
And if you do a trace now 15, 127, 254, 143.
Let's see if we run up here, 15, 127, 254.
This is before we did any of the summaries.
So his network path is basically the same,
but the tables on each one of these devices is less,
which makes processing that much faster on each one of these devices and
the requirements for each one of these devices goes down.
So with that let's move on to the next section,
which talks about how two different features, including summary, limit the query boundaries for EIGRP.