Now we have this summary-route in here to Null0 which is also called the bit bucket. Basically it’s a road to nowhere. It’s a way to get rid of certain packets.
So you look at this and you think “well why am I getting rid of certain packets here? why is my summary here on the router (doing the summarization) pointing to Null0?”
Well here’s why. Let’s go ahead and take a look at the entire table
and we’ll see all of our connected routes. They’re not going to be gone from R1 because they are connected routes. And we also have that summary out there.
Well the thing is if a packet comes in for 100.6.1.1 (our loop back on that 100.6.1.0 network) the entry in the routing table that is going to match that, is the highlighted one, because we’re looking at the longest match here.
We like to keep our routing tables complete and concise because it’s not like an ACL. We run an ACL top to bottom and as soon as we get a match that’s the end of it.
Well that’s not the case with the routing table. Parsing the routing table is the technical way to put it. Every time R1 has to route a packet, it’s going to look through its entire table looking for the longest match. In this case a packet going for 100.6.1.1, the longest match is the route that I have highlighted for you. If you wrote that out in binary, it would be a 24 bit match. 100.6.1 would match exactly. where the summary would match for a few bits but it’s not going to match for 24 bits.(red)
So anything that comes in for a connected router at this point (any of our connected routes), the route that R1 would use to finish the routing job would be the connected route.
What if that 6.1.0 route wasn’t in the table? What if we had a scenario where we put this particular summary route in but 6.0 was not in there?
We’re going to just take it out.
We may need to check our numbers to make sure it’s loopback6 first(with ‘show config’) and then take it out.
And you do get a message there “Not all conflict may be removed and may reappear after reactivating the interface and sub interfaces.” So basically what that means is if I go back to interface loopback 6 right now, it may have the same IP address on there and I would need to take it off.
So right now if we look at the routing table
The entry for 6 is gone.
Now if a packet comes in now for 100.6.1.1, what’s the longest match for it now?
It would actually be the null route… That would be your best match . Then the packets just simply get dropped.
This is a routing loop prevention behavior. You’re only going to see the Null0 route on the router that’s actually performing the summarization. This is not going to be advertised out.
We saw that with R2 & R3, that it did indeed have the summary route but that’s why the null0 route is there on the route doing the summarization. It’s simply to prevent routing loops and saying “OK I got this packet for 100.6.1.1 but I’ve got no other match for it.
This is the best one so I’m going to drop it in the bit bucket.”
Now about that AD of 5, here with the summary highlighted, we don’t see an AD here.
And notice it is mentioned as a D route there. (D for EIGRP) So we expect to see that, but we expect to see an AD here too. And as a quick refresher, on R2 :
There’s the AD of 90, and over on R3:
as we’d expect, there’s the AD of 90. So what about this AD of 5?
Let me show you a way to expand on the ‘show IP route’ command (and a couple ways you can do it here)
We’re just going to go with the numeric one
I put in ‘show IP Route’ for 100.0.0.0, and it tells you how many known subnets there are, six of them are attached, variably subnetted with 2 masks, and that’s even going to show you what it is.
So we have our entries here, and the 6 network is gone. But I still see don’t see an AD of 5 anywhere. what’s the mask for our summary? because we could put that here and get even more specific.
And look what you finally see… a distance of 5.
SO now you know exactly where to look for that… show IP route, and then just put your summary in, and your summary mask, and you’ll actually see the 5.
I want to just show you that graceful resync message over on R2 that I mentioned to you, and to do that we take the summary address off and then hop over to R2
And there we go.
This is the message you would see on R2 when we took that summary address off and you’ll notice it even mentions “peer graceful restart”. So if we ran ‘show ip route eigrp’ :
you would see there are your subnets and everything is beautiful.
And if we do a ‘show IP EIGRP neighbor’ :
you can see the adjacency never really went down, because under the up time we’re well over an hour and 20 minutes on each one.
Bandwidth Review
only reminder I want to give you here as far as bandwidth goes is that this is not EIGRP specific command.
Other features on the Cisco router can use this value. So when you’re changing it you can’t have tunnel vision and say “OK this is just going to affect the EIGRP”! You need to look around and see what else is running on that router (maybe some quality of service which will introduce you to later, or maybe some other features that use that value) and you just want to be careful with that. Also notice that it is in kilobits not in megabits. So that’s definitely something to keep in mind.
Now as far as the delay value goes, you can also use this to fine tune routes.
But I tell you I’m going to use bandwidth that I possibly can and frankly I probably use another method if I possibly can. And you’ll learn some other methods in future studies but as far as the delay goes:
throughput delay is fine but you’re dealing here with tens of microseconds. So as you can imagine it could be pretty challenging to get close to the metric you want or close to the tweak that you want. So I just want you to be aware of that that it can be pretty darn tricky to get the result you want and I promise you that is the only value we’ll see that is time based.
