This lab is based on real world networking ,where some of the hubs were in major cities but some of the spooks were rural and the networking connections were not always the best.
On this occasion we would make a decision to not use a routing protocol over a link to some of those spokes, because the connectivity just wasn’t there.
Whether it’s an unstable link or an unstable client, sooner or later you’ll run into a situation where you don’t want the overhead of a dynamic protocol. Sometimes a static route can actually be better and that’s fine.
But the decision to use a static route in a situation like that can make using a backup route a little tricky.
You’ll see what I mean in this lab:

Here we’ve got two links. Two different ways for packets to get from R1 to R2 loop back over the broadcast segment Fast Ethernet network of 12.1.1.0/24 or over the serial link through the service provider cloud at 21.1.1.0/24.
Now we’ve seen a network kind of like this already (and you put RIP on it. We know it had equal cost load balancing etc.) But in this particular case what’s going to happen is the client has come to us and said “Hey that Serial lead is not particularly strong. It flaps a lot.
I don’t want any routing pack overhead…”
Whether it’s an unstable link or an unstable client , on occasion you can have something happen like this where the client just says “Hey I don’t want a routing protocol configured on that serial link.” But they do want a backup link.
Since R1 can reach R2’s loop back in two different ways (VIA 12.1.1.0 OR 21.1.1.0), we love that.
We love the redundancy but in this particular lab we’ve been told that serial link is unstable and that leads the client to make some unusual requests.
- We’re not allowed to run a dynamic routing protocol over the serial link.
- We should run RIP over the broadcast segment the 12.0.0.0 segment
- The serial link (21.0.0.0 segment) should be used to reach R2’s loopback(2.2.2.0) only if the RIP route for that network actually leaves the table.
So that RIP route has to be totally gone in order for us to be able to use that 21.0.0.0 segment.
So this is what we’re actually going to do here in a moment.

I’ve not pre-configured RIP, but what we’re going to do is configure RIP version 2 over the broadcast segment and on R2’s loopback.
But we are not going to configure it over that serial link.
Little different here
What are the first two commands I want to put here.
And the order doesn’t matter but the first two commands are almost always going to put on a RIP are ‘no auto’ and ‘version 2’

and I’ll go ahead and put the network statement here…
and R2… almost the same thing.

And we need one for that loopback…
and let’s go on back over to R1

We run ‘show IP protocols’ and let’s just review a couple of these very important commands

We see Version 2 all over the place there in the middle. We see automatic network summarization not in effect (exactly what we expect to see).
There is the routing information source gateway 12.1.1.2 the downstream router, AD of 120 and last update came in a few seconds ago.
And notice it’s running on fast Ethernet RIP ( we are not running anything over the serial link).
So let’s go ahead and run ‘show IP route rip’ and take a look at all the rip routes in our IP routing table.

And as we expect there’s 2.2.2.0 and everything looks good expected next hop, expected interface, everything looks as expected and We’re going to ping it to make sure we can reach it.

OK I pinged it but how do I know that these packets aren’t going over that serial link? What am I going to do?
I’m going to trace route.

That’s going to show me (in this case) one address (the very next hop address 12.1.1.2). we have verified that everything is going over the broadcast network.

So right now we’ve got all traffic going to 2.2.2.2
But we don’t want to ignore that serial link, and right now if that route disappears from R1’s routing table what’s going to happen?
There’s nowhere for the packets to go!
As a matter of fact let’s go in and test that…and the quickest way to do it is to go over to R2 and take network 2 out, and then force an update:

We’ll see if we still see the route

and we don’t.
So the RIP route to network 2 is gone.
So what happens if I try to ping 2 now?
the packets are just going to time out because we don’t have any gateway of last resort… there’s no default gateway here.

So we know beyond a shadow of a doubt that the packets are going over our broadcast network and we also see now that if that route disappears, R1 cannot communicate with R2’s loop back.
We want to fix it so this serial link is used when that RIP route disappears.
So before we proceed with that and before I forget let’s put network two back in the mix.

And we’ll go back up to R1, and see if we see it (force an update again)and we can just make sure everything is back the way it was


it was and it is.
So if we can’t go dynamic, we’re going to go static.
We’re going to write a static route that will send traffic over the serial link and then we’ll test our connectivity.

and we can I still ping 2 2 2 2 short and nothing has changed.
And let’s go ahead and do a show IP route RIP

and my RIP are out is gone! Why is the rip route gone from the routing table?
The only thing I’ve done is I added that static route 2.2.2.0 using the serial link.
So why is the rip route gone?
let’s do a show IP route static

and there it is! There’s the static route.
So let’s use ‘show IP route 2.2.2.0’ and we see it’s known via static.

And let’s go ahead and send a ping we know we get connectivity but let’s run ‘trace route 2.2.2.2’

Next hop IP address is changed to 21.1.1.2 .
So right now just by writing that IP route command, all the packets going to R2’s loopback network are going over the serial link which is exactly what the client didn’t want! because it’s an unstable link.
Why did that change?
I want to verify for you that the RIP update for that network is still coming in from R2 over the broadcast segment.
I run ‘debug IP rip’ and ‘clear IP route * to force an update

and you could see we’ve got a version 2 update from R2 over the broadcast segment.
There’s the network so it’s not like it’s not getting the RIP route because we wrote the static route. That one didn’t cause the other.
So what exactly is going on here right now?
Right now the router is learning about that network(2.2.2.2/24) from two different sources.
RIP and the static route.
Now Since the mask is the same length for both of the updates, we got to have a tiebreaker.(administrative distance is the tiebreaker)
Static routes have an AD of 1 where RIP routes have an AD of 120, so the static route is going to be installed into the IP routing table.
The only way the RIP route is going back into the IP routing table is if that static route disappears and we’re going to make it disappear in a minute because what we have right now doesn’t meet the requirements of the lab because all the traffic from our R1 to network 2 (2.2.2.0) is going over the unstable serial link which isn’t going to make our client happy.
Very first thing I’m going to do here though is take that static route off. (use the up arrow to go through the history and then use Ctrl+A to go to the front of the line and type ‘NO’)

So right now if I run ‘show IP route rip’ you’ll notice the RIP route is back in the table because that static route is gone.

And what we need then is some other kind of static route.
If we raised the administrative distance of the static route to a value greater than 120, the RIP route would be installed in the routing table and it would stay there, because we see it’s back now after taking the regular static route off, and the floating static route would be used only if the RIP route disappeared.
We can raise that AD by configuring our static route as a floating static route. When we raise the AD of a static route, that’s what makes that a floating static route.
It’s kind of floating out there in limbo. That’s kind of my explanation that’s not the official textbook explanation.
And it’s just floating there until it’s needed.
And right now with that RIP route of an AD of 120, if we give the static route an AD of 121 then it should just float out there and only enter the table if it’s needed.
Before we start the config, I’ll remove the current static route and then check the IP routing table’s RIP routers (We already did that).
So let’s go ahead and take a look at a floating static route
The command would be ‘IP route’ and then 2.2.2.0 and we’re going to go with the same mask and we’re going to go with the same Next hop IP address and you’re thinking “Boy that looks amazingly like the regular static route you wrote” and it is!!
Let’s check the values of the very end here though.

Now we don’t see the word “floating” here anywhere.
So it must be something else. What is it?
It’s that distance metric for this route.
What you’re doing when you set that? it doesn’t say administrative distance but that’s actually what it means. (Distance metric for this route).
So there is no rule that says you just need to set this one higher than the routing protocol in action, but it’s good best practice.
So what I’m going to do is set the AD of this floating static route to 121
and I get I still have other options but I don’t need any. And that’s it.

So does that little 121 on the end of this command really make that big a difference?
Let’s find out… let’s go ahead and ‘run show IP route rip’

and we see that that’s still in the table ( even if we force an update it’s still going straight into the routing table.)
So the floating static route that we wrote it’s floating out there right now. it’s not in use.
And if we use ‘show ip route static’ :

Nothing there! because that route is not in the routing table.
Let’s run ‘show ip route 2.2.2.0’

you can see I put an extra 2 in there! but it showed routing entry for 2.2.2.0/24 because that match the address I put in.
And we see it’s known via RIP, distance 120 and everything is as we want it.
Let’s go ahead and do a ‘trace route’ anyway

you can see the next hop IP address for packets going from R1 to R2’s Loopback.
The next hop is 12.1.1.2 so everything is beautiful.
But we got to test this thing. How are we going to test it?
We’re going to take 2.0.0.0 out of R2 Config.

and I’ll hop over to 1 and we’ll do a show I peer out rip see if it’s left the table yet

and already has…
So if things are working correctly now when I run ‘show IP route static’, we should see the static route, we should see an AD of 121 in them when we do a trace route, it should be using 21.1.1.2 as the next hop.
Let’s find out what happened:

There it is! The static route is now in the IP routing table because this is the only other source of information that this router has about it.
But thanks to the AD of 121 this route wasn’t put into the table until the RIP route was gone.
So that’s exactly what we wanted to see.
And once we run ‘show IP route 2.2.2.0 :

We can see: ‘known via static’ there’s that distance (again) of 121 So that indicates that we do indeed have a floating static route and we will do a quick trace route:

21.1.1.2 ! So we have met all of our requirements.
Everything is going just as we wanted it to.
We’re running a routing protocol over the broadcast network.
We’re not running any routing protocol over the backup point (the serial link). We’re using only a floating static route which enters the table only when the RIP route is gone so you can see that little 121 has a big effect and it really comes in handy on occasion.
And just to test things let’s make sure to put network 2 back in.

And by doing so once R1 sees that update, the static route that we wrote (the floating static route) should leave the table and the report out should be back.

And there it is.
Now if we run ‘show ip route static’ here:

We see nothing.
And one more time I’ll run trace route for 2.2.2.2

It never hurts to check in one more time before you leave a client site. You see the next hop is again 12.1.1.2 (a floating static route)…
We’re going to introduce a default route in an interesting way in RIP and we’ll give you a little bonus information that goes a little beyond the CCNA but it’s good stuff to know. And that is all coming up next.
Originating a Default Route With RIP
We’re starting with a blank slate for this particular lab and no diagram because I want you to get used to the fact that sometimes you’re going to go into a client side or maybe even have to handle an exam question practice or otherwise without a nice neat diagram.
You’ve got to learn a little this information yourself as to what’s going on.
I haven’t planted a problem here for you but I just want you to get used to gathering information on your own rather than always having a picture there.
So what is a really good command just to even get started to see what’s running on this rally right now as far as a routing protocol?
‘show IP protocols’

You always come home to show IP protocols and you can see here that I first off configured RIP and I did take the previous configs off from the last lab and then put some new ones on.
So that’s what we’re actually gathering information on here.
And you can see I left the defaults as far as the timers. We’ve seen that sending up data every 30 seconds quite a while now, but we can also see that I did successfully hard code version 2 for sending and receiving.
We also see that I have got eight loopback interfaces that I’ve enabled RIP on, so I’ve got something different going on there.

Assuming you knew the 172.12.123.0 network was the one we’re working with and you’d see that with show config.
We can also see that we’re getting information from 123.2 and we know where that is from all these labs. We know that’s R2.
If we’re routing for these two networks (highlighted ones) and we know that 172.12.0.0 is the serial network then what network must I be running these loop backs on?
I must be running them on 20.0.0.0 and we’ll have a quick look and just verify that on show config.

And there are the loopbacks

and you can see exactly what I’ve done here is taking one address from each of those eight subnets, put on the loopbacks, and we know that I’m advertising them with RIP.
So right now if we go down to R2 we should see an individual entry for each one of those subnets

and we do… and we’ll ping some of them:

That’s why I love ‘show IP protocol’. You can walk in without a diagram and not knowing what’s going on. Then you run that, you write out a couple of things and all of a sudden you’re on your way.
So we’re never really trouble shooting anything here because there’s not really a problem here with this particular routing table.
But I think you know already what I’m going to say… We really like our tables to be complete and concise… and you know what screaming at us right here… is this 123.1 next hop IP address for every single route in this table.
So what we could do is configure a default route and that would bring the table down while still allowing R2 to communicate with all of those loopebacks (and frankly any loopbacks that were added because the next hop is going to be 123.1 period) .
How can we do that? We’ve already done a default static route. I want to show you a different way of generating a default route.
I’m going to make a couple of pointers here. if you haven’t even seen OSPF before, don’t worry about it. But I’m going to mention it here because the command I’m about to show you is also a popular OSPF command and it works a little bit differently in OSPF than it does in RIP. So when we get to the OSPF section I will mention that again and we’ll draw a clear line as to what this command does with RIP and what it can do with OSPF.
So with no further due, let’s see what this command is.

We’re going under the RIP router process and it starts with default:

There is a lot of options just for default route.
What we’re using here is a command called “default-information originate”.
And there is a pesky little hyphen (-) here in between default and information.
First couple times you entered in a lab environment might trip over that! just watch out for that! And here’s the definition: ‘control distribution of default information’.
It’s not terribly helpful!
Let’s go ahead and see exactly what this command does because the only option I have with this is originate.

Then we have a ‘route-map reference’ and route mapping is for your future studies and you do not have to worry about it right now. But notice that I don’t have any other options.
And when we come to distribute a default route, I assure you that I do not have a default route here on R1.
So what’s going to happen if I try to originate or distribute a default route in RIP on R1 if I don’t have one? Let’s hit enter:

So nothing bad happened there. let’s go now on R2 and have a look at our RIP routing table

and we’ve got a new route.
Now again R1 did not have a default route to distribute, but the default information originate command in RIP, allows a router to advertise the default route that it actually doesn’t even have.
So that’s a pretty powerful command.
We love this because we see the ‘R*’ there. we know that asterisk indicates the default route. There is administrative distance, there is our metric, there’s our next hop IP address and all this is wonderful but notice that all of the non-default routes are still in R2’s routing table and that’s not really what we want if we’re trying to shrink the routing table down.
So I want to show you that by default, the default information originate command in RIP has couple of things to notice about it.
First off (we’ve already seen this but I want to mention again) R1 did not have a default route to distribute but the default information originate command allowed it to do so. It’s advertising a default route but it’s not doing anything about the more specific routes.
And that’s why we see all these RIP routes down here.
Now if we want to filter these out, there is a way to do it. It’s beyond the scope of the CCMA exam.But I am going to show it to you because it’s a handy thing to know.
This is what I was talking about about filtering these routes out but you need to understand access lists first and that section is coming up.
So what we’re going to do in the access list section, is revisit this lab. We’re going to come right back to this point and I’m going to show you how to filter the routes out then . If I show it to you now it might not stick with you because some of you haven’t even seen an access list in action yet and I don’t want you to see them until we do some walkthroughs and some simple or work with them.
So we will come back to this.But again those are some important points with that false information originate command with RIP.