RIP is a distance vector routing protocol that uses hop counts as its metric to undergo a best path selection process. It can be considered somewhat effective for small networks but problematic for larger network as it transmits its entire routing table to its peers every 30sec. We will leverage the following topology to demonstrate how to configure it and some of the things to remember when dealing with RIP.

Before we hop onto the consoles, let’s discuss few things we need to know about the protocol:

Distance vector protocol are somehow considered legacy in a sense where they typically have limited scope of the topology due to the fact that they only acknowledge directly connected interfaces. Another limitation to consider here is the fact that periodic updates are sent regardless of network change events. On top of that, all of the routing table is sent during every update; You do imagine the amount traffic that’ll be sent and received just to keep the neighbor relationship up if you have a large routing table ?

RIP has 2 versions which are RIPv1 and RIPv2. The main difference between those 2 is that RIPv1 is a Classful routing protocol and RIPv2 is a Classless routing protocol.

*Classful routing protocol do not send the subnet mask information with their updates. Hence, Variable Length Subnet Masks (VLSMs) are not allowed. Hence, summarization is not allowed.
*On the contrary, Classless routing protocol do send the subnet mask information with their updates. Hence, Variable Length Subnet Masks (VLSMs) are allowed. Hence, summarization is allowed (CIDR).

In today’s modern network, Classful routing protocol (RIPv1, IGRP) are almost not used anymore. Well, I’ve never seen it in a production network and I certainly would not deploy it in a production environment as it does not support contiguous subnets.

Another major difference is that RIPv1 periodic updates are broadcasted out to the address 255.255.255.255 whereas RIPv2 sends its updates via multicast to the address 224.0.0.9. This is major in terms of performance !

It’s also important to note that RIPv1 does not support authentication whereas RIPv2 does.

Okay very well ! Let’s now hop onto the consoles and configure RIPv2 on RouteLeak-HQ…

Notice how all you need is the command “router rip” to enter into the rip process. “Version 2” sets the version mode but you need the “no auto-summary” command to allow VLSM. If no version is defined under the process, then version 1 would be the default version.

Also, when configuring the network only the major network boundaries are needed here. If you were for instance to type in “network 10.1.1.0” and check the router configuration, you would see that it would be converted to “network 10.0.0.0”.

Let’s configure our remote routers…

All right ! noticed here what we’ve just discussed about the “network” command ?

At this point, we should see the 172.16 network and the 10 network via RIP from both remote offices. Let’s check…

Notice here how the “R” validates that the route is a RIP route. Also notice the AD which is 120 for RIP routes as well as the next hop address to reach the destination.

Once the network command is entered, all interfaces that belongs to that subnet will be part of the RIP process. In order to stop advertisement out of an interface, the command “passive-interface” can be used but it is important to remember that it only stops the advertisement meaning it can still receive advertisement. Additional configuration will be needed if you wanted to disable RIP completely such as configuring an access-list that denies all traffic and then use the distribute-list command to apply the ACL inbound to the interface.

Also note that the output of the command “sh ip protocols” displays useful information as well such as the network advertised, the version used, the AD and so on. Let’s do that…

Very good ! One thing we haven’t talked about is the fact that RIP has a maximum hop count of 15. Every router is basically considered as 1 hop. Now, imagine if you had a router that’s 16 hops away from the source ? You probably already guessed that the packet would be dropped at that point. Let’s see that in action…

First let’s create a couple of loopback addresses at the 2nd remote office…

Let’s now redistribute the loopbacks into RIP (I will have a post about redistribution soon)…

Here, we created a Route-Map and matched the interfaces we want to redistribute. Since we are dealing with connected prefixes, we need to use the command “redistribute connected” and tie it to the route-map instance.

Let’s now see if Remote1 can see them as RIP routes…

Very good ! Let me now show you how we are going to prove that RIP has a maximum hop count of 15.

First let’s enable debug on both routers and see what type of messages we get…

All right, now let’s poison the routes for the loopback prefixes by setting the metric to 16…

Let’s analyze our debug output here…

Here, we can clearly see that Remote Office 2 is in fact sending the updates to the Remote Office 1 but RO1 has marked those entries as “inaccessible” due to the fact that the hop count is 16 which is higher than 15. Let’s check the RIP database and the routing table to make sure the routes are no longer on Remote1…

Very nice ! The routes are no longer in the RIP database as well as the main routing table. We’ve clearly seen the routes being advertised out via Remote 2 and received by Remote 1. However, they were not installed in the routing table due to excessive hop counts. For the sake of proving this further, let’s set the metric to 14 for instance and check the RIP database and the routing table on Remote 1 again…

Ahh ! By setting the metric to 14 we can now see the routes being received by Remote 1 and advertised by Remote 2. We have successfully demonstrated RIP’s limitation in terms of hop counts.

That completes this topic… I’ll talk to you guys later.