Now we’ve got the usual EIGRP network set up here. 123 over the cloud, 23 over the ethernet segment between R2 & R3.
But what I don’t have on this diagram, are seven loopbacks, and I just didn’t want to draw seven lines and squeeze all the numbers in there but you’ll see them all in just a moment.
And I’ve already got them advertized into EIGRP with the network command so you know what letter they’re going to have next to them in the router table (AD)
R1 is the one actually doing the advertisement. As you see right here on R2:
These seven subnets are all being advertised into EIGRP by R1. R3 has them too (we’ll go around take a look around) and you can see the AD of all seven routes is 90 because they are internal EIGRP routes, and the next hop of course is 123.1 for every single one. And of course they have the code D for which stands for EIGRP…
Now again is a couple of things we’re seeing like passive interfaces. There is nothing technically wrong with this. And if we go back to R2:
we can ping all of them and there’s nothing wrong with that.
So if we run ‘show IP route EIGRP’
again absolutely nothing wrong with this table but would it be great if we could narrow it down to two routes or narrow it down to one?
Well actually we can do that with route summarization and it does help when the numbers are consecutive here (as we have 1 – 7 for the second octet) and route summarization is about it’s about as easy as it gets.
Manual Summarization
Auto-summarization is a pain, but manual summarization is a great thing when used at the proper points in your network. Here are just a few reasons why:
- The routing tables are smaller, making the entire routing process faster.
- Since the tables are smaller, the load on the CPU from the routing process is lessened.
- Routing updates themselves are smaller.
- The more-specific network numbers are hidden, a small boost to our overall network security plan
- The impact of flapping links on the rest of the network is lessened.
- Overall number of the EGRP queries can be lessened.
R1 is advertising those seven EIGRP routes and it’s 100.1.1.0 through 100.7.1.0, and you can see I gave them /24, so you can also see they’ve been in the table for about 12.5 minutes. So how would we go about summarizing them?
Well first off we’ve got to break them down into binary (just the first two octets) and keep going from left to right with all of the addresses until they are all no longer the same.
It’s at that point where your routes are summarized. You don’t even know they are summarized yet but they are!
Each one of these routes has the first 13 bits in common. All we have to do is convert the binary that you’re looking at in bold, and then put the mask behind it and you’re done.
So here we’re looking at 100.0.0.0. But that itself can’t be the summary because we got to have something to go with it. We’ve got to have a mask to go with it.
The mask is going to be ones for all of our common bits, and zeros for everything else.
So the first thirteens are 1s for your mask. That’s it. So that would be 255.248.0.0 or /13.
You could express it either way on the exam.
And that’s exactly what we’re going to summarize this route and see what happens in the real world:
First of you’ve got to figure out where to put this the summary, and the summary actually does not go in the EIGRP config. It actually goes on the interface. That’s the first thing to remember…
And as you can see there are a lot of IP options from there and we’re going to go with ‘summary-address’ ( Perform Address summarization)
So you’re probably wondering when’s EIGRP going to get mentioned? Well it’s going to get mentioned right here:
If we were running RIP on this router, we could send out a summary address but we want to do EIGRP.
You can change the administrative distance of these. It’s very rare that you’re going to do that. We’ll talk about leak-map later. So I will hit “enter” button
A little neighbor change there…
If we go to R2 and do ‘show EIGRP neighbor’ :
you’ll see the up time has not changed. There’s R1 at the bottom, It’s 34:30 so we just had a a graceful resync and the adjacency stayed up.
So now what’s going on with that table?
100.0.0.0/13. There’s our summary and notice that the summarized routes (the more specific routes) are gone. That is not a universal behavior. In your BGP studies you may bump into some summarization where the summary addresses advertised both the summary and the more specific addresses. But EIGRP doesn’t do that, you’re just going to see the summary address that you’re advertising in these summarized routes are going to be gone.
We go to R3 and check that.
We send some pings around(100.1.1.1 , 100.4.1.1 , 100.6.1.1 ) and and we’re looking good. Then we go to R2 and send ping to 100.4.1.1. and then do ‘ show ip route eigrp’
Did you notice those something kind of odd about that summery route? The oddity is the administrative distance, which is always the first number in the brackets. The AD is 90, and if we go over to R3(two pics ago) there is the code of D which we expect in the entry and then it has an AD of 90(red)… but you’re taught (by me!) that the AD of this route is 5 !! So that’s kind of interesting.
What if we take a look at EIGRP table on R1?
Well we’ve got an entry here as well. Of course we would never see the loopbacks here because they’re connected routes. But we do see a summary route. And then something called a “Null0”! That’s no zero… That’s an interface called Null Zero… I don’t think we bumped that before.
So we’re seeing a couple of oddities here… but our pings are working. That’s what we’re really concerned about. But what’s this Null zero thing on the summarizing router?
