Intro To Distance Vector Protocols
RIP versian2 is a good way to get started with routing logic and going beyond the walkthrough as we did earlier and we will do plenty of debugging we’ll see RIP v2 in action in plenty of lab work here in the section.
But first we need to go over some distance vector protocols and a very brief history lesson.
RIP v2 is really the last distance vector protocol standing. It’s the last one you’re going to see in today’s production networks and frankly you’re not going to see a whole lot of it.
Now I’m not down talking. It does have its place inside you know private network but it’s not one that you’re going to see used over wide area networks very often.
Now the original version of RIP is rarely if ever used but it is still available.
The original IGRP was a distance vector protocol and today it’s not even available on modern Cisco routers.
The enhanced version of IGRP which is EIGRP (the E stands for enhanced) is a major part of today’s network. You can’t go anywhere without running into EIGRP. It’s going to be all over future exams as well.
But right now we’re going to stick with our distance vector protocols.
The problems with RIPv1 and IGRP:
- they both sent a full routing update at a fixed interval. (RIPv2 does this as well). And you might look at that and say well this is not so bad full rounding up data every once in a while. Every once in a while might be one thing but by default would be every 30 seconds and it’s really unnecessary because hopefully if your network is so unstable that routes are changing every 15 seconds then you should probably be fixing that and not be here!! You don’t need those full routing updates like that and what you’ll see with our other protocols with OSPF and with the IGRP is that the notification happens when there is a change and only regarding the change network. If you have 90 RIP route, you don’t need 90 RIP routs advertised for every interface on a router twice a minute. That’s just a waste of resources all the way around.
- IGRP and RIPv1 did not understand variable length subnet masking (VLSM) but RIPv2 does, and if you’re not familiar with VLSM hang in there with me.
- They also didn’t support any kind of packet authentication. Occasionally we might want to set it up so the routing update we’re getting we know we’re getting it from a trusted source and with RIPv1 and IGRP that could not happen. RIPv2 does offer that.
Routing Loops And The Admins That Hate Them
About routing loops you want to watch these terms on your exam. Routing loops happen at Layer 3 and switching loops happen at Layer 2 and at Layer 2 we have something called the spanning tree protocol to help us prevent switching loops.
Routing loops happen at Layer 3 and this happens when packets are on their way to the destination, but somewhere in the middle they end up going around in a logical loop rather than moving on to their final destination and the packets finally just time out.
So your packets are leaving but they’re not getting where they’re supposed to get, and they’re getting lost in the middle.
Now the DV (distance vector) protocol behaviors were designed to stop routing loops.
They’re very good at that, but they can cause serious headaches for you on occasion especially the very next one called split horizon.
Split Horizon
The rule of split horizon is very simple.
A route cannot be advertised out in interface if it came in on that interface in the first place.
Now that’s me being a little less fancy about it if I was going to state the rule formally I would say that a route cannot be advertised via an interface if that same interface is the one that learned about the route the first place.

So if this route we have on the board 20.0.0.0/8 comes in on Fast Ethernet 0/0 it cannot be advertised back out that interface.
Split horizon is not enabled on serial interfaces that run frame relay.
And for those of you that that doesn’t mean anything to you it will later in this particular section. But that’s one time split horizon is disabled by default. All other times it’s going to be enabled.
Route Poisoning
Well what we want as often as possible is a nice quiet stable network where all of our routers have reached what we technically call a state of convergence and it is just another way of saying all the routers agree on the routes that are available even the ones that are not. (router agree on the current state of network). Their routing tables are much the same and they are not currently updating their tables.
A major reason that you don’t see much distance vector routing out there anymore is that these protocols are painfully slow to converge, even in a lab environment.
I’ve had little three router labs that you know I’ve put RIP on and do a demo and even then when you change something when you added a network especially when you subtracted a network removed one then they could really become a pain to deal with and that’s where poisoning comes in because that sounds like a really negative thing.
But it’s actually a positive thing for our networks. And you will see why …
Split Horizon and Poison Reverse
Time for us to see what could be so positive about something that has such a nasty name -route poisoning- Well here’s an example of a distance vector protocol walk through.

A R3 is connected to 10.1.1.0/24 is advertising to R1 and R2 that that network is one hop away.
Hops… not a very scientific metric. But that’s the only metric that distance vector protocol’s understand. It’s called just a hop and it’s just like what it sounds! one router to another is one hop, and to the next router is two hops etc. so you can see another reason we might not use that. we’ll revisit that later.
But R2 is getting an advertisement and sending it out another Interface and it’s going to R1. So R1 at this point is hearing about 10.1.1.0 /24 from two different sources and it’s going to look at that and say: “OK that’s the exact same route, but the metric is different it seems to be faster if I go through a R3 as opposed through R2. So we love this situation because we’ll take all the redundancy we can get. If R1 loses one path to 10.1.1.0/24 it has another one and we kind of like that! so everything would be fine here until that route goes away.
When a route becomes unavailable, we want all the routers to know about it and to know it as quickly as possible.
Many people think that is R3 would just stop advertising it. well there is a problem there because if R3 simply stops advertising it, we’re going to run into an issue and I must show you what it is here. And just as a quick reminder what I’m showing you next is without Route poisoning.

R3 says: “OK 10.1.10/24 is unavailable.I ‘ll stop advertising it.”
The problem is, that doesn’t do anything about the entry in R2’s routing table.
So R2 is just going to keep telling everybody (and in this case that includes R1) : “Hey I know Where 10.1.1.0/24 is! It’s two hops away!” even though the network itself is now unavailable.
So it’s not enough for R3 to stop advertising it. It’s got to have a way to tell everybody else : “hey that route isn’t around anymore”.
Eventually R3 is going to get an advertisement from R1 and say: “hey that route is now available via R1! I’ll put it back in my routing table and start advertising it again!”

What you end up with is a heck of a mess, with three routers advertising a route that no longer exists. R1 sends down an update to R3 eventually, says: “hey I know where 10.1.1.0 is! it’s three hops away”, and if that network is down on R3 it’s not going to be in the Routing Table. R3 looks and says: “hey OK I’ll just put that in my routing table and start advertising it, and 10.1.1.0/24 is four hops away.”
So you can see again the trouble we end up with here, and this is how all routing loops form if this were in the center of a larger network.
So we end up with a real problem if we didn’t have Route poisoning but fortunately it’s on by default. We do have it.
So what happens in the case of route poisoning?
Instead of ceasing to advertise the lost route, R3 will continue to advertise it but it will do so with a poisoned metric.
RIP only understands hop count and it understands that a hop count of 16 indicates an unreachable route.
So that is the metric R3 advertises with the route.

So this is what we have in our network instead, because Route poisoning works.
This is what happens: R3 doesn’t stop advertising it. R3 continues to advertise it but with a poisoned metric. That’s where the name comes from and it’s telling R1 and R2: “hey you know it’s 16 hops away”. R1 and R2 get that update and say “hey I’m going to take that route out of my table and I will stop advertising it.”
So as a result of that poisoned update, R2 will no longer advertise the route up to R1 or vice versa.
So that’s what a route poisoning can be a force for good.
The “Hop Count” Metric
Neither version of RIP is very scientific when it comes to determining the metric of a network segment because again the hop count is the only thing it understands.
Which one pf these two segments would you consider the fastest?

Now you and I could look at a gig Ethernet link and a 56 K link and say I think the gig Ethernet link is a little bit faster.
But the problem is RIP or any distance vector protocol considers these two links to be the same speed. It’s one hop. It’s the same metric to RIP. RIP can’t differentiate.
Now you could go in and do some tweaking and make it understand but we really don’t want to be in that business because we have other protocols we’ll learn about later that we’ll see what is going on there with the speeds and we’ll adjust.
But distance vector protocols by default are not going to adjust they’re just going to use that hop count.
Full Routing Updates, Every Time, All The Time
IF your network is literally changing every minute you should not be watching this video you should be at work. And I kid (mostly).
But another major issue with RIP is that it sends full routing update every 30 seconds. We want a nice stable network. We do not need an update especially a full routing update every 30 seconds by default, because these unnecessary routing updates first they take up bandwidth and suck up valuable router resources.
In contrast, EIGRP sends a routing update only when there has been an actual change to report, and even then, the update contains only the changes, not the entire EIGRP routing table.
OSPF handles things a little bit differently but it’s much more efficient than if distance vector protocols handle it.
But before I’m accused of RIPv2 shaming, v2 was quite an improvement over v1 And here are four that I think you should know:
- V2 supports subnet masking (variable length subnet masking) v1 does not.
- V2 multicast its updates to 224.0.0.9 rather than broadcasting to 255.255.255.255, as v1 does.
- V2 offers update authentication, v1 does not.
- v2 allows the network administrator to configure route summarization manually. V1 doesn’t allow that
This is where we’re going to start with RIP and it should look awfully familiar.

We’ve got our 172.12.123.0/24 network running on our serial interfaces on all three routers. Our service provider cloud or frame relay cloud we’re not configuring that because that’s our service provider and we have a loopback interface on routers 2 and 3 there isn’t one on R1 yet.
RIP Lab
Time to get acquainted with RIP now and some not so complex commands but definitely one squarely default we’ve got to be aware of.
We’ll see that right away.
Now we I have checked connectivity over the 172.12.123.0/24 network. 1 can ping 2 etc. etc…and the loopbacks are present on Two and Three and of course they can’t be pinged because right now we don’t have any static route or anything going on as far as a routing protocol, but that is about to change.
I want to show you one thing before we start our Confg. I’m in R1, and I ran a command called show IP protocols. we’ve seen that before. But what I really wanted to point out to you is that every once in a while you’re going to run a show command and it’s going to skip a line as you can see here and then just go right back to the cursor.

And I just want to let you know that doesn’t mean that something is wrong on the router but it does mean that there is nothing to show you and this is common with 99% of the show commands that you run.
You’re not even going to see little headers or a table or anything! that’s empty.
You’re just not going to see anything. So don’t let that freak you out.
It just means that right now we don’t have any protocols running.
We are about to change that and we’re going to start with ‘conf t’ here and ‘router rip’ and unlike other routing protocols that you’ll study later there’s nothing else outside of the router rip command when you want to start to rip config, (any numbers or any values anything like that) as you can see with ios help here.

We literally don’t have anything else we can do here except hit enter. So we’ve dropped down and I’m going to use the network command first to enable RIP on any interfaces on the 172.12.123.0/24 network and you just put the network number here.
Now with RIP you can put the major network number if you wanted to because this is probably going to show up a little bit differently in the config. We’ll take a look here in just a moment and what you’ll see also is that we have no options with this network command and in later protocols that you study EIGRP and OSPF in particular you are definitely going to have some options there.

So as you can see RIPs are pretty simple to run. And let’s do a quick ‘show run’.

Look at our RIP config to date and you can see that you’ve got 172.12.0.0 here even though I entered 172.12.123.0.

That’s always going to go back to the major network number, and since this is a Class B network that major network number would be 172.12.0.0. So don’t let that mess you up either so we’ve got that rock and roll.
And now let’s run the show IP protocols at this point.
Now we haven’t gone to the other two routers yet but we do have something running here.

And this is a great command to run over and over and over in the lab environment.
In a production network it gives you a wealth of information and going from top to bottom though you can see on the third line routing protocol is RIP. we’ve got some filter list information here first and we don’t have any filter set.
But here’s one reason we really don’t like RIP.
it’s ‘sending that full update table every 30 seconds’ and we’ve got our next due in 13 seconds of course when I ran this command.
Don’t concern yourself with these other timers (the next line)
We’ve got redistributing rip. It’s going to say that even though we haven’t configured any route redistribution it’s always going to name the protocol right there.
And default version control:
Here’s that oddity! that squirrely default I want to tell you about. We got two versions of RIP. We know that. We know the similarities. We know the differences… and you would think that when you run RIP, it would either be running all v1 as far as sending and receiving, all v2 as far as sending or receiving or sending and receiving both.
But as you can see that’s not the case. By default a RIP enabled interface will accept either version an update in either v1 or v2 format, but it’s only going to send v1 updates.
Pretty odd!!
And the thing is we don’t want that. Because we know the deficiencies with version 1.
We want the subnet information. we want all those great things that come over at v2. So what we want to do is hardcode the router so it will send v2 and accept v2 and then that’s it. And you’ll see here it’s going to give you this information on a per interface level. And right now we only have one interface running RIP. So it’s saying: “hey you’re sending version 1 updates but you’re accepting versions 1 and 2”.
Note this sentence carefully: ‘Automatic network summarization is in effect.’
We’re going to see if that’s good or bad a little bit later on.
‘Maximum path: 4’ Rip performs equal host load sharing, so if there were more than one path to get to a destination and they had the exact same metric (and we know the metric with RIP is hop count) then it would start sharing the load over those paths and by default it’s going to do up to 4 paths by default.
‘routing information source’ and it would look like we don’t have any.
And right now we don’t have any because router was the only router that we’ve configured anything on.
So we certainly hope as we add to that that we will start seeing some routing information sources namely R2 and R3.
‘Distance: Default is 120’. that’s definitely not a metric. It’s definitely not hop count.
So what is that?
We’re coming back to that in a later lab.
So before we go to routers two and three we’re going to hard code R1 to only send v2 updates and only accept v2 updates and we do that actually one of two ways.
I want to show you both ways.
Rarely you’ll see this but you can do it at the interface level.
>int serial 1/0 >> ip rip ?

And then you see the options here for receive and send.
So if you really want to get particular on multiple interfaces on a router and you want to send an except v1 on one interface and send an except version 2 on another, you can do that and you would just do ‘send version’ and then one and/or two you would have the option of doing both.
So you can do it on a per interface level.

What I recommend you do and what you’re going to see most of the time is that you just do it period! You tell RIP : “Hey wherever you’re running I want you to run all version 1 or run all version 2”.
And you do that under ‘router rip’ and the command is ‘version’.
And you’ll notice this command does not give you the option to put one and two. You got to choose one or the other.
So we’re just going to go with version 2 and we will verify that really quickly.

As you can see that default version control has been changed we changed the default to send version to receive version 2.
We also see the interface is sending and receiving version 2 and we’re all set there.
The next line says ‘ automatic network summarization is in effect’
A lot of people think that automatic summarization in Rip is off by default.
But as you can see it’s not it’s on. That’s really important that we disable this because it’s going to mess up our routing tables.
It’s going to get a little confusing and when we do our automatic summarization lab later in the session you’ll see exactly why.
The full command is ‘no auto-summary’ . you’ll see this is “no auto” so often in books labs practice exams maybe even the exam. So you really should be used to that.

So let’s hop down to router 2 and ‘router rip’ going to do a version 2 and a ‘no auto’ and now we’re going to enable RIP on our loopback interface and also on 172.12.123.0 (serial interface) and that’s it.

And we’ll go over to R3 and will do the same.

and now we have enabled RIP on all our interfaces and we have the version agreement. everybody is sending version 2 updates and receiving version 2 updates.
Let’s go up to router 1 and see what we can see first off with show IP protocols because we should see something different here now

And you can see that we do under routing information sources, and you will see the address of the source you will see something called a distance again and we’ve got a distance here of 120 and we’re going to see it again here in a moment.
That it’s also going to show you how long it’s been since the last update came in.
So let’s go ahead and run show IP route and we’ll see if we see these routes.

There they are.
And also R stands for Rip route.
So we see our subnets and there’s a number 120 again in the brackets.
We are going to cover that. And the second number in the brackets is always going to be the metric of that particular path. And the reason I’m mentioning that of course with one we know what that is. it’s “one” hop. this is RIP.
What’s the highest that number can be without the route being taken out of the table? 15 ! because if that were 16, it would be considered a poisoned route or rather an unreachable route and it wouldn’t even be in the table.
Let’s go ahead though.
What do we need to do before we leave R1? We need to ping those addresses because as we saw in the static lab just because you see them in the table doesn’t mean you can ping them so let’s go ahead and ping both of those.

It goes right through.
So let’s head back to the diagram for just a moment.

And now we’re going to see if R2 (one of our spokes) can ping the other spokes loop back and then we’re going to ping R2’s loop back from R3.
First off though we got to make sure the entries are in the table.
So let’s head to your R2

and you can see the RIP table here though only shows 3.3.3.0 because of course 2.2.2.2 is a connected network.
So let’s go ahead and see if we can ping there

and looks pretty darn good.
Let’s head over to R3.

Just want to get you used to these filters because nothing wrong with doing show IP route.
You’ll also notice that with some iOS versions when you run a filtered routing table command, you get the full code table sometimes you don’t. And the key here though is that your codes (or your routes or I should say your routing table) can get bigger than one screen. So sometimes you don’t want to look at every single route in your table.
You just want to look at the RIP routes, or the OSPF routes are a particular route and here I just ran ‘show IP route rip’ to filter it and only get the RIP route. Very handy little command.
Let’s see if we can ping 2.2.2.2

and we can! So that looks pretty good.
Now go back to the diagram for a moment.
We talked about the role of split horizon and that rule states that a router cannot advertise a route out of interface if that’s the same interface the router learned about the route on in the first place.
So in this case why is it that R1 can successfully advertise R2’s loopback down to R3 if R1 is advertising that route out the same interface it learned about the route on in the first place?
R1 is learning about R2’s loopback on serial 1/0. That’s the only interface it’s even talking with right now. So R1 is learning about loop back to there via serial 1/0, but then it’s sending an advertisement to R3 the same way (same interface). How is that happening?
Well that’s the one default I mentioned I know I’m throwing a lot of stuff at you so I want to remind you of this.
The one time ‘split horizon is disabled by default’ is when you are dealing with a serial interface on a frame really network. And that’s exactly what we’re doing right now.
So that is why R1 is able to advertise the routes -the loop backs- out the same interface that’s learning about them on in the first place. But what if you wanted to turn that off?
What would it look like if we did that?
We want to turn split horizon back on, on R1. We’re going to override that default that happens on a serial interface when you’re running frame relay.
And also I’m going to show you a very helpful command it’s not just for RIP but it’s really helpful to get over the slow convergence of RIP and for some routing updates.
Let’s go ahead and head back to R1. I’m actually going on the interface itself and I’m turning this on. And for those of you who have been doing this for a while it can be really easy just put no IP split in. But we’re not doing it here. You’re so used to turning split horizon off in some situations that here we’re turning it ON.
So what you want. The command is IP split (the full command is likely IP split-horizon) and if we were running EIGRP we could specify that and then an autonomous system number.

Don’t worry about that yet or even what autonomous system number is because all we need right here is IP split horizon.
Now what I’m going to do is force a rip update and I will explain this command in just a moment let me go and run it all three routers.

I mentioned several times one thing that gets frustrating about RIP is its slow convergence and even turning split there off I’d have to wait a couple of minutes for the routers to realize what was going on and the new updates to go out and come back in and get put in the tables. So instead of waiting what I did is I forced an update with RIP like clearing the routing tables and note the asterisks that I put there. Let me show you the ios help… not a lot of options here.

I very rarely use these other options so don’t even concern yourself with those.
What I would like to use this for is ‘clear IP route *’ and what that does it deletes all of your dynamically learned routes.
Now your static routes and your connected routes they’re not going anywhere.
But it will empty your routing table of all dynamically learned routes.
So what happens then?
Whichever routing protocol you’re running it’s going to go ahead and start an update immediately. It’s like “hey I’ve got no routes.”!! It’s like you just configured that particular protocol.
You’re not going to run this a lot with the EIGRP and OSPF in your later studies because those protocols converge so quickly but RIP as we know does not.
So this is a great command especially for lab environments when you just want to go in force and update instead of sitting there looking at your watch and waiting for RIP to catch up to you.
So let’s have a look at R1’s routing table right now Or the RIP table and we see the same routes we saw here before and I’ll go in ping them.

so we’re good there.
Let’s head down to R2

and look at that! we don’t have any RIP routes!!
Therefore there is no way in the world we’re going to be able to ping 3.3.3.3 and if we do, it will be just going to die out. So I’ll go ahead and kill that ping.( It’s control shift 6 control shift six that escape sequence.)
Now let’s have a look at R3

and R3 doesn’t have any RIP routes any longer either. Why? Because now split horizon is in effect! we just enabled it! so R2 is sending its ad for its loopback up to R1.
R1 gets it on serial 1/0, looks at the update, puts it in the table and then that’s it.
It’s not going to advertise it back out to R3 because of the rule of split horizon. It learned about loopback2 (that particular network) on 172.12.123.1 and now that we enabled it,
it cannot advertise that same route back out the interface and the same thing is going on with R3’s loop back.
So right now neither spoke is learning about the other Spoke’s loopback because of split horizon.
So if we want to go ahead and turn split horizon back off it’s just ‘no ip split’.

I’m going to go and do some Clears (probably just need to do that on R1 but I’m going to do all three

and now we shouldn’t see any changes here on R1

But now on two and three.

And there’s three back because we turn split off and we compete with no problem.
We go over to R3

There’s R2 back again. we ping it again and everything is beautiful.
Important to remember with split horizon is that if you’re running a serial interface and it’s on a frame really network which is exactly what we have here then split horizon is going to be off by default.
It wasn’t that way for a really long time believe me, because the first thing you would type when you’re configuring the interface was ‘no IP split’ but here that gives you a great idea of what happens when split horizon is enabled you can see as I mentioned when we’re talking about that how can come back and bite you every once in a while and here it definitely would.