The Dangers of Autosummarization
RIP did ok by us in that previous lab, but one thing we did was we turned auto summarization off because I wanted us to concentrate on other things. If we left all of those summarization on, it was going to mess up our routes and I want you to see exactly what auto summarization can do to the routing table, that may look good but as we’re going to see with some connectivity tests, it’s actually not all that good.

And what I’ve done here is:
For R1 we had to do a quick hardware swap. It’s going to be Serial 0 instead of Serial 1/0 but everything else is the same including the IP address.
R2 and R3 are our spokes just as before.
Everything is as it was before on the 172.12.123 network.
What I did though is take off the previous loopbacks and I’ve taken two subnets of 20.0.0.0/8 and put them on R2 you can see what those are 20.1.1.1 and 20.2.1.1 respectively and then two more subsets of that major network number on 20.3.1.1/24.
And the thing is this has an awful sounding term.
In summary, the loopbacks from the previous lab have been replaced with two subnets od 20.0.0.0/8 on R2 and two other subnets of 20.0.0.0/8 on R3.
When you put subnets of one network number on one router and then you take subnets of the same network number and you put them elsewhere in the network(on different routers), these are called discontiguous networks and it sounds terrible and you may think you should fix that.
Well actually you don’t have to fix that. This is much more real world and not as bad as it sounds. But RIP has a little bit of a problem with this when we leave auto summarization ON (at its default)
Right now I’m going to bring up R1’s routing table. We’re not going to do the Config because we already did that, and again the commands are used are same ones as in the previous section (version 2 and then the network commands and then that’s it).
So let’s take a look at R1’s routing table and here it is with ‘show IP route rip’

and this might not be what you were expecting because we have the subnets out there 20.1.1.0 , 20.2.1.0 and so forth.
But we don’t see those what we’re seeing is the major network number 20.0.0.0 / 8 , and also notice we have two next hop IP addresses for this one route.
What we’re seeing here is a combination of two behaviors, and the first one is Rip’s load balancing behavior (equal cost load balancing I should say)
When RIP sees multiple paths to one particular destination, and the metric is exactly the same -as it is here, 1 and 1 (120/1 and 120/1)- , RIP says: “hey we should load balance. We shouldn’t use one of those paths to get to destination A. We should use all of these paths and we’ll split the load up equally and go from there.”
That sounds great in a lot of cases (next section I’ll show you how that can work in our favor) , but the problem with equal costs load balancing is we have these auto summarized routes (and I’ll show you exactly why they’re being auto summarized in a moment), and RIP is going to load balance anything we send to any of those four subnets but we don’t want that to happen.

If we’re sending packets over to 20.3.1.1 over on R3, we don’t want that to be load balanced. It sounds like some of the packets would get through and then some of them would go over the R2. We don’t want that.
Same goes for 20.4.1.1 . Same goes for all four these subnets, and the reason the routes are being auto summarized is because we left auto summarization on and here’s why it’s working.

R2 is going to have two subnets that it’s going to advertise via RIP, but the problem is they’re being advertised across what we call a network boundary.
The routes for 20.1.1.0 are being advertised across or out the 172.12 Network. So that’s a network boundary and RIP’s default behavior here is to summarize the routes that are being advertised and that’s why we’re getting that funky result up on R1 (instead of seeing the subnets we’re seeing just the major network number). Same things happening over on R3, so that’s why we have this load balancing going on right now.

R1 is saying: “hey I’m getting an ad for 20.0.0.0/8 from R2 and I’m getting it from R3, so when I send something to that network, I’ll split the load up.”
We can actually see the summarized routes by debugging RIP, And I’m going to run ‘debug IP rip’ and then I’m going to run our friend ‘clear IP route asterisk’ to force an update

‘u all’ of course is the Southern expression for “undebug all” . And you can put on de-bug all in there if you want to but I usually just do ‘u all’

you can see we’ve gotten some updates here.
Here’s ‘received v2 update’ and this is the one that came from R2. And the next line you can see the route has been summarized (20.0.0.0/8) and we got received v2 update from 123.2 and also 123.3
So we can see that the routes are indeed being summarized
But the real tipoff to spawning an auto summarization problem is when you get a ping result that is just bizarre. And so far I think we’ve seen five exclamation points, or five periods , or U.U.U but if not we’re going to see something here!!! because I’m going to try to ping one of those subnets around R3 and you can see how odd looking this one is.

The thing is it’ll be a little different every time.Now we got one success and four timeouts that’s not good.
Let’s send it again now and see if we get the exact same thing.
We’ll try and 20.4.1.1 and you can see we’re getting just timeouts here and now.
Let’s try the others.

Yeah there we go and it’s really unpredictable You never know how this is going to go because I’ve done this auto summarization up for years and years.
When you send the pings you some will go through. Some will not.
Sometimes you’re going to have a ‘U’ in there for “unreachable” that especially when you ping one of those and you’re getting three success packets and one failure and one unreachable, that is a huge tip off when you’re running real that you forgot to turn auto summarization off.
So now that we’ve seen the de-bug we’ve seen the summarized routes with see what happens, let’s go ahead and turn auto summarization off.
The Cure for Autosummarization
Before we continue, let’s hit you with kind of a practice exam question (also a job interview question) because in a production network you’re going to see “no auto” under every RIP config you see more than likely, and you put it on even when you don’t need it.
I do the same thing. It’s just “route rip no auto” because you don’t know what’s going to happen in the future after you leave (as far as route summarization goes and what they’re going to add).
But let’s say as a job interview question or practice exam question or Cisco exam question on which of these routers would I absolutely need no auto summary configured in order to resolve the issue we’ve seen so far? Do I need it on all of them?
I’ll give you a hint. No!
The answer is you need to put it on two and three in this lab because no auto summary needs to be configured on the routers that are doing the actual summarization. And the reason I’m even asking you this, is just to impress on you that the no auto summary command prevents automatic summarization, but does not undo it.

So if we put it on R1 right now it doesn’t really hurt anything, but it’s not going to have an effect as far as the route summarization right now.
And what we’re going to see hopefully with a debug and a show IP route command, is once we put it on Two and Three and do a few clears as far as the routing table goes (because after all this is RIP and has slow convergence) hopefully we’ll see our subnets then and we’ll have much more accurate routing going on. But you always need it on the routers that are actually doing the summarization.
Well let’s go ahead and see that in action we’ve got R1 and there are the two routes right now.
We’ll go to R2, do ‘no auto’ and then clear the routing table

Then R3

And we’ll clear it up here too. We’re going to force the heck out of it since this is RIP.
in case you’re wondering you will rarely run clear IP route asterisk with your other routing protocols EIGRP or OSPF. I’m not going to say you never do it but it’s pretty close. And let’s run a ‘show IP route rip’ and there we go.

That’s exactly what we wanted.
And again any time (practice exam, real exam or real world) if you’re expecting to see subnets like this with RIP, and instead you see just the unsubnetted major network number, practically guarantee the problem is that auto summarization has been left on.
Also notice that I never did ‘no auto’ on R1 because router was is not doing any automatic summarization right now.
I will go ahead and do a ‘no auto’ there so we have it all three right now.

And that is it.
So we’re seeing our subnets now. We’re going to send a couple of pings around.

they’re all going through and it is a beautiful thing.
You’ve already seen de-bug IP RIP in action so I’m not going to run it again here.
But instead of seeing the summerized number that we saw before you would see the individual subnets coming in.
So again you know what to look for. Auto summarization is actually easier to fix just by spotting that and un-summerizing number in the routing table.
Passive Interfaces

We’re going to take a look at passive interface and see first off what a passive interface is and how it impacts our network and how it can make life a little easier on one of our routers here in particular, because as you can see I’ve kept the addressing the same from the previous labs. But over on R2 I took the loopbacks down that we were using previously and I brought up our two fast ethernet interfaces that we have on that router and assigned those IP addresses that were on the loopbacks over to the fast ethernet interfaces so operationally and pingabilitywise we hope nothing has changed.
All the other commands have remained the same. Version 2, no auto, and the appropriate network commands on each one of the routers.
Here you can see just to make sure I sent some pings from router 1 over 20.1.1.1 and 20.2.1.1 and were in great shape there.

We’re always looking to improve things a little bit.
We got to watch that with a distance vector protocol because as I’ve mentioned a couple of times, not only does RIP is into full routing update every single time it’s time to send one, but it sends one pretty darn often.
Remember the command that shows us how often that is? ‘show IP protocols’

There is a ton of great information here. And as you can see here are the timers and by default RIP is sending an update every 30 seconds.
So we’re going to live with that for right now over on R1. But R2 is a different animal

Right now I’ve connected router2 to a couple of switches and in turn those switches are connected only to Hosts. So there are absolutely no devices off of fast ethernet 0/0 or fast ethernet 0/1 that need those RIP updates.
Therefore it’s silly for us to send them because everything we do has a cost.
Router 2 has got to package those updates and get to send them out the interface that takes up a little bit of bandwidth and it’s just not something we need.
The problem is that those updates are enabled by the network 20.0.0.0 command.
And if we take that off a R2, R1 would no longer see these particular networks.
So it’s not so easy as just taking the network command off.
This is where the passive interface command really comes into play and really is quite helpful because what the passive interface command is going to allow us to do, is prevent sending the routing updates out the interfaces that we deem passive. But at the same time the network command can still advertise them.
So we’re going to see that in action right now because we’re going to go over to R2 and do ‘show IP protocols’ here…

Much the same kind of information and we see a couple of three interfaces.
Now we see that they’re hardcoded to send and receive version 2.
We see that autosum is turned off. Do you see anything there about passive interfaces at all? I don’t either!
Let’s hope that changes. Because we’re going to verify our passive interfaces with this command when we’re done.
Oddly enough, passive interfaces is not configured on the interface you’re going to make passive. It’s actually going to be configured under the routing protocol which in this case is RIP. Let’s run ios help here.

You can see down near the bottom, passive Interface suppress routing updates on an interface and that’s exactly what we want to do.
I’m going to run ios help again.

And you see the many many many types of interfaces we can have.
Don’t worry you’re certainly not going to see all these on the exams. So just giving you the full list here of possibilities on this router.
It does not mean that you have some of these running on the router ( like CTunnel or Dialer interface). It’s just going to give you the full list of possibilities.
Also notice at the bottom:

‘default suppress routing updates on all interfaces’
If I wanted to I could use that option to make every interface on the router passive, and something you might not want to do, because of course in this case on R2 the routing updates will no longer go up to R1 and it will go downhill from there.
So you want to be selective about that. Let’s go ahead and just put fast 0/1 here.
Before we do that though there was something else I wanted to show you and that’s with the de-bug, because we know theoretically those packets are going out )the fast ethernet interfaces) but we want to see them. Let’s go ahead and run a ‘debug IP rip’ and then our new best friend ‘Clear IP route *’


The first clue that you can see that fast ethernet 0/0 and 0/1 are indeed sending updates, is when I cleared the routing table of dynamically learned routes, RIP immediately is sending requests and look where the requests are going.
They sent a couple requests out the serial interface but also sent a couple of requests out both of the fast internet interfaces.
Now this is interesting too and you’ll see this in de-bug IP RIP.

We’re actually kind of officially getting a packet from each one of those IP addresses. It says: “ignored it because it was sourced from one of our routers’ local addresses.”
We’d like to get rid of that too. passive interface will help us out with that.
But you can also see where we’re receiving the updates on the serial interfaces.

There is fast and at 0/0.
Here’s an update we’re sending out 20.1.1.1 . It even tells what the IP address of the interface is at the very end.
We know this is 224.0.0.9 and that we know that’s version 2 because Version 2 multicast were version 1 broadcast (just a friendly reminder)…and with fast ethernet 0/1 20.2.1.1
So we are definitely sending out updates at those fast ethernets interfaces.
We’re going to turn that off and then do test connectivity and make sure R1 can still get to those two networks.

So we just made those interfaces passive. That’s all there is to it.
Now… How are we going to verify that? You already know both ways.
Let’s run ‘show IP protocols’ first

and now notice we have passive Interface information.
So when you don’t have any interfaces that are passive on the router, show IP protocols isn’t going to show you anything. It’s not even going to have a blank field in there, but once you make some interface is passive, It will indeed show here.
We’re also going to verify it with our debug



and we’ll clear that routing table again )and never get tired of clearing routing table with RIP)
I’m going to let that run and see if some more updates come in.
But notice first off here at the top, once we cleared it, we sent two requests out Serial 0/1/0 but no requests went out the fast ethernet interfaces. And you’ll also notice everything else we have here we received version 2 updates on the serial interface but we haven’t seen anything from or sending out via the fast ethernet interfaces… We waited about half a minute and you can see sending the two updates 224.0.0.9 via Serial 1/0, but we have successfully prevented any routing updates or requests going out the fast ethernet interfaces. The great thing is if something changes, (if someone added a router or a fast Ethernet 0/0 or that was changed from a Layer2 switch to a layer3 switch) and it needed the RIP updates, it’s simple enough to take care of. You just go in to router rip I’ll show you exactly how to do that.
With most Cisco commands (not quite all but most of them) you can negate them by putting the word ‘no’ in front of it .

Note: If you do the up arrow and then the down arrow that’s going to go through the history of your commands and let’s say that I wanted to put just ‘no’ in front of them, if you hit control, the cursor goes to the front and you can add ‘no’ …and there you go.
And you could verify that again with show IP protocols

and you’ll see now that we only have 0/0 as passive.
If we do a quick debug


and you’ll see the requests they are now near the top.
You’ll see right there sending request on fast ethernet 0/1. So we have successfully made that interface not passive.
Let’s go and make it passive again and then we’ll go up to R1 to check things out.

And that’s all there is to it. And I’m going to clear the routing table here and let’s do a quick ‘u all’ there to help R1 out and then we’ll go up to R1 and do a quick ‘show IP route rip’



and we can…and that’s it.
So fantastic… Passive interface did exactly what we wanted it to do.
We’re still advertising the route successfully but we are suppressing routing updates from going out a couple of interfaces that frankly they don’t need to go out.
Now let me just remind you of this. It’s a handy little thing to know because let’s say that you had 10 interfaces on this particular router -Loopbacks, Fast Ethernet, Gig Ethernet, Serial- and the only interface that you wanted to send routing updates out, was the serial interface. You wanted to suppress them on all the others.
Now you could put in nine separate passive interface entries, but you could also do this:

You could do the passive interface default thing and then do a ‘no passive interfac for the one or two interfaces you didn’t want to be passive.
So that’s another approach.
With two interfaces entering two separate lines we can do the first approach and no big deal but for 10 interfaces or 15 interfaces and a ton of loopbacks you don’t want to sit there and make them passive one by one. You can just make them all passive with default with the passive interface default command and then enter a no command no passive interface for the interfaces that you don’t want to be passive.
Administrative Distances
So far in our labs, our routers have only had one source of information for a non-connected route. It may have been a stiatic route, It may have been a rip route, but there was no choice that had to be made.
But in some cases especially in production networks, a router may hear about a given route from multiple sources, and the router has to make a decision as to which route to place into its IP routing table and which protocols going to be used to handle traffic for that destination.

Here’s a router getting an update for 172.12.123.0 both from EIGRP and RIP.
Now the one difference here is that the EIGRP subnet mask is one bit longer than the update that’s coming in from RIP, and there’s nothing wrong with a router running multiple routing protocols.
So this router is running EIGRP and RIP, and it’s hearing about the 172 12 123 0 zero network. Which route is it going to put in to its IP routing table?
Well in this case administrative distance does not matter!
The first value that’s considered in this route choice is the length of the subnet mask.
In the previous illustration the EIGRP route has a mask of /25 while the RIP route has a mask of slash /24.
The EIGRP route is considered the longest match, and the EIGRP route would be put into the IP routing table.
It doesn’t mean there’s anything wrong with the RIP route. It’s just that EIGRP route is considered superior. If that EIGRP route was lost and then that rip route was the only one coming in for that network, then of course the RIP route would be used.
So Admin distance didn’t come into play there. When will it come into play?

Well there’s just a 1 bit difference between this diagram and the last but that one bit does make all the difference because now the router’s hearing about 172.12.123.0 /24 from two different protocols. It’s hearing about it for EIGRP and also RIP. So which route is it going to put into its IP routing table.
This is when administrative distance comes into play. Remember the longest match is the first thing that the router is going to check.
Administrative distance is strictly a tie breaker. That’s all it is. Here we have a tie. We’ve got a couple of 24 bit masks for the exact same network and now administrator distance is going to be used to decide which route to choose and then of course which protocol is going to be used.
Administrative distance is a question of believability. The router has to decide who’s more believable, EIGRP or RIP.
You can always find the administrative distance of a route inside the brackets in the IP routing table.
You’ll have two numbers there. The first one is the AD, and the second one is that route’s metric. The RIP routes on R1 from our previous Lab all have an AD of 120 which is the default AD of RIP. (The time shown is the length of time since the route has heard about in an update. As we know, that time in RIP will always be less than 30 seconds.)

R stands for RIP
Then we have our Subnets. In the bracket, 120 is the AD and the one is the metric and those metrics will get a little bit bigger when you get up to EIGRP and OSPF, but for RIP a metric of 1 is certainly understandable (we know that’s a hop count)
It’s going to say ‘via’ an IP address that shows the next hop IP address, the timer that we see is the amount of time since the last time we heard an update about this particular route. And we know with RIP that’s never going to be over half a minute by default.
But though OSPF and EIGRP it will be much longer because we don’t have those twice a minute updates… and then the local router’s exit interface to reach that destination is going to be at the end of that line.
The lowest AD. is considered the best AD.
The lower the administrative distance the more believable the source of the route.
So in this case the router is going to choose that EIGRP route over RIP in the tiebreaker.
Here’s a partial list of admin distances, all good Ads to know for your exam prep.
It’s a little awkward to show you an entire table of ADs when you haven’t seen a lot of these protocols in action yet. But Cisco wants you to know these now, so let’s know them!
(I would memorize these frankly! You’ll see a couple of them in your CCNA Studies)
But I think it’s a good idea for you to know all of these numbers.

The connected routes: That’s the only route type that will not have the brackets I mentioned, and what you’ll see there is just nothing and a connected route is considered to have an administrative distance of zero.
Note: You’ll see discussions online occasionally about whether a static route has an AD of 1 or 0 depending on whether you use the exit interface or the next hop IP address when you’re writing it. Leave that alone! Cisco’s static route is one.