The Perils of Autosummarization
EIGRP once had a pesky little default behaviour called autosummarisation. The future is no longer on by default, but it can be enabled, so we need to be aware of it.
Autosummarization occurs when routes are advertised across classful network boundaries. That doesn’t sound all that bad, but when you have discontinuous networks, it can cause real trouble.
Discontinuous networks are subnets of the same major network number that are separated by another network number. In the following lab, we have subnets of 20.0.0.0 separated by a different major network number, 172.12.0.0.
You’ve got the usual 172.12.123.0/24 network going between routers 1, 2, and 3.
We’ve got loopbacks on R2 & R3 (I’ve already configured these) where I’m using subnets of the major network number 20.0.0.0. That allows me to use a couple of subnets on R2 and a couple of subnets over on R3 (subnets of the same major network number)
Officially, these are discontinuous networks and again it’s not evil! It’s one of the reasons we use subnets.
The problem is that EIGRP is going to have a little bit of trouble with this. And by the way a RIP version 2 does the same thing. And with EIGRP again it’s off by default but it can be turned on. Let’s see how it’s going to be turned on and we’ll see this autosummarization in action. What we see here is the subnets of 20.0.0.0. It’s being summarized as they are advertised across a network boundary (the 172.12.123.0 network).
On R1, the routing table is going to end up having a classful entry for 20.0.0.0/8, and
what does EIGRP do by default? it equal-cost load balances. So what’s it going to do here?
On the diagram, I already have the EIGRP adjacencies running between the three routers over 172.12.123… I have not yet added the subnets of 20.0.0.0 to the network. What I did do is enable autosummarization on all three routers so you could see what happens when we do that, and I’ll show you how to disable it and to re-enable it. Very simple stuff.
But what you want to do is run ‘show IP protocols’
and in the middle, it’s going to mention “Automatic network summarization is in effect”.
That’s because I use the auto summary command to make it happen. This is where your eyes play a little bit of a trick on you, because you see this so often as automatic network summarization is not in effect, and it’s one small word but it’s a huge impact on the network. So I always take an extra second when you run ‘show IP protocols’ to check out network summarization and just make sure it says “is in effect” or “is not in effect” to make sure it says what you want it to say.
So let’s go ahead down to R2 and check our adjacency
we’ve got our adjacencies there that have been there for almost 20 minutes, so all is well. Let’s go down the R2 and we’re going to put the wildcard mask here.
We’re going to revisit what just happened there.
you notice it says “re sync”… it resynced when I did that and noticed that it said “summary up”… there’s your first hint that some kind of summarization just took effect… and then “remove components”. So it resynced it but didn’t drop it.
Let’s go over to R3 and see if the same thing happens
Same message! it’s almost as if some kind of summarization just took effect automatically.
So I’ve got a couple of resynced neighbors there but you know everything else looks fine and we can run ‘show ip eigrp neighbor’
You can see the up time here is 20 minutes 18 seconds so we’re fine there, it’s not like it dropped.
Let’s go ahead up to R1 and we’ll check our adjacencies first (make sure everything is OK with R2 as well).
And we see that they’re resynced. They did not go down and go back up. So the up time kept on incrementing. And now let’s run ‘show IP route eigrp’
And this is the problem with auto summarization because I don’t want these routes to be summarized right now they’re going to cause me trouble. Right now EIGRP is performing equal-cost load balancing and when I try to send packets to one of these subnets (look at the diagram), at least two of them are going to go to the wrong router! Because we’re equal costs low balancing.
If I send packets to 20.2.1.1 right now what’s going to happen? Well let’s find out.
That is one ugly return… U stands for “Unreachable” (the worst return you can get on a ping when you’re trying to get packets somewhere because a couple of them are timing out and then a couple of them are just saying hey I don’t even know how to get there.)
If we do 20.3.1.1 (ping one of the two networks on each of the spoke routers)
and I’m getting this horrible return because of auto summarization.
So what I want to do is undo Automatic route summarization and let me ask you this.
Pop Quiz: You’d probably just go and turn it off on all three routers. But where exactly do I have to turn auto summarization off to resolve the issue we’re running into right now? Where would I have to configure it?
Answer: I would have to configure it on R2 & R3, because if I just turn auto summarization off on R1, I’m not doing anything! I’m not helping myself in this situation, because the summarization is already been done. ‘NO auto summary’ will prevent a router from performing auto summary. It’s not going to undo auto summarization that was done on another router.
So we’ll go ahead and just do it on R2 & R3 . And also that’s why we had that little “resynced” because the routes were being summarized and we actually saw that in the message where it said “summary up”.
So any time you see that, you know it’s not like anything went down. But it’s a hint that maybe you ought to check things out.
So let’s get into R2 & R3
and your command is going to be right near the top (auto-summary) and the definition is “enable automatic network number summarization”.
Again I don’t want to scare you off route summarization. It’s a very important tool and you’re going to find a lot of uses for it throughout your studies and throughout your career.
But I recommend you do it manually.
And you’ll notice we’ve got the “resync” again. It says “summary configured” but that really is reflecting the fact that it’s Non-summary configured. Let’s go over to R3:
and we’re going to leave it right there and everything’s good.
And now we have our subnets and you see the entries
even though the adjacencies didn’t go down, (you can see the up time there is still like almost 25 minutes for that two) you see now that we have our individual route entries, and now when I ping across, they’re coming right back.
That U.U.U is always a hint that something’s wrong, but I would check my routing tables right then and there, and again if I were working with either EIGRP or RIP v2, I would check to see if auto summarization is off or on… and where you’ll see that. is definitely something you want to eyeball.
Just run ‘show run’ and then go under the eigrp
and you see we haven’t taken it off of R1 yet. But it didn’t hurt anything.
I’ll go ahead and do it while we’re here but always check that and just do an extra a little second of an ocular scan there, and make sure it says “auto-summary” or “no auto-summary”.
I’ll go ahead and fix that here. And you can see the resync there. It’s not going to change any routes because R1 is not advertising anything. But right now we’ve got everybody set to “no Auto-summary”
Let’s run ‘show IP protocols’
and that’s where you want to check and it’s that magic word “Not”
So we need to know where to turn it off and how to turn it off which is certainly simple enough. But watch that where! because if you’re limited in the number of routers by an exam question (if a question said What’s the minimum number of routers, or at a minimum where would you need an auto summary?) you’ll need to put it on the routers that are performing the summarization, and not the one that is receiving the summarized route.
Passive Interfaces
We’re going to use the passive interface feature which is also in EIGRP to cut down on some overhead and some unnecessary packets leaving R2.
So we saw this in the OSPF labs as well and the concept is really the same. We have the packets going out that Ethernet interface on R2 and we want to stop them. But the thing is if we stop them by taking the network command off, R1 will no longer have the network 23 in its routing table.
So let’s take a look at R1 first
and you can see there is the network and we’ll go ahead and send a ping just for fun and all is well.
But in previous labs we’ve had other EIGRP devices on that segment, and this time we don’t have one. So if we go down to R2 and run ‘debug IP eigrp packet’
you’ll get a carrot! Let me show you your choices here:
I want to show you one particular EIGRP debug though. You have some options here but they’re not really what I want!
You may want to just go here:
and here are some other debugs that you might want to run and ‘packets’ is the one I wanted to show you
it’s even going to list the packets… right now we’re going to watch some Hellos and go out interfaces,
This is a lot of unnecessary traffic. Let’s do a ‘u all’ right there.
When you run ‘debug eigrp packets’, some of these look pretty darn familiar.
And some that we haven’t seen yet (IPXSAP, probe, ACK, SIAQUERY (stuck in active query) and SIAREPLY (stuck in active reply). We’re saving that for another day.
Any way I ran this one to make sure my Hellos are going out and coming in the way they should if we have an adjacency issue.
Right now we don’t have an adjacency issue. But what I would like to do is stop those hellos from leaving the interface because they’re totally unnecessary in our lab.
So what I’ll do is use the passive interface command (it’s under the router process)
syntax is really the same, you’ve got all of these different interface types, and also next to the bottom, you have the default option that we also had with OSPF.
So if I wanted to make every interface on here passive, then I could just do passive interface default, and then if I wanted to un-passive one, just put a word ‘no’ in front of the passive interface command.
So in this case I just want to make fast ethernet 0/0 passive
and that’s it. We’re not going to get any messages about losing adjacencies because we didn’t have any.
And it certainly will not affect the one that we do have, and that’s with R1
but that’s the serial interface. So let’s go over and run that packet debugging again
After a bit of waiting, we got a hello from 123.1. We’re actually though getting the result we want.. We’re not seeing those hellos anymore. So they’re no longer leaving the interface so we just cut down on a lot of overhead with one simple command.
And the key is to go up to R1 and we’ll do first ‘show ip route eigrp’
and then we still have the route and we can still ping that device… and of course if we brought R3 back online now, we would need to do a ‘no passive interface’
Any time you want to take a passive interface off (and that’s under EIGRP process), just bring passive interface back up, Control moves the cursor to the front, Put the word ‘no’ in front of it.
and of course always do ‘undebug all’ before you leave the client site or finish a lab (short for that is u all). That’s going to turn off all of your debugs.
