In this article I will write about the RIP routing protocol and give a quick overview of the inner workings. Even though RIP does not have as much usage in the enterprise environment as other routing protocols, it is still useful to know how it works. We will be implementing the following basic topology for our lab:


Let’s start by assigning IP addresses to our interfaces.

R1(config)#interface fastEthernet 0/0

R1(config-if)#ip address

R1(config-if)#no shutdown

R2(config)#interface fastEthernet 0/0

R2(config-if)#ip address

R2(config-if)#no shutdown

Finish the configuration on the other interfaces and make sure that you can ping the neighboring routers IP address when done. The cloud that you see in my diagram is actually a Microsoft loopback interface that I have connected to GNS3. Make sure to disable keepalives on the R2 fast Ethernet interface that connects to C1 or otherwise you won’t be able to ping your loopback interface. The command to disable keepalives on an interface is the following:

R2(config-if)#no keepalive

At this point in time we have basic connectivity between our devices but no routing protocol running. Let’s go ahead and enable RIP on R1, R2 and R4 for the network and start analyzing what will occur.

R2(config)#router rip


Enable RIP on the other two routers using the above commands. When we enable RIP, R2 sends a RIPv1 request to the broadcast address. This tells us that RIPv1 uses broadcast messages to communicate which is inefficient since devices that don’t care about the communication will end up receiving these messages.


Digging into the packet structure we can tell that RIP uses UDP at layer 4. This makes the RIP routing protocol communication unreliable and it doesn’t provide recovery in case of packet loss. Something that caught my eye is that the TTL value is set to 2. This is interesting because the time to live value is only decremented by a layer 3 device or a router. RIP only communicates with directly connected routers to share network information. This process is known as routing by rumor since a router is relying on the information received by another router and it is not capable of verifying if it is true or not. If the RIP protocol only relies on other routers that are 1 hop away then it doesn’t make sense for this value to be set to 2. Doing some research seems to suggest that back in the day there might have been certain devices that reduced the TTL value before processing the packet first. If the TTL was set to 1 and it was received on an inbound interface on another router then it would reduce the TTL to 0 and discard the packet before even processing it.


Moving forward to layer 4 we find that the port that RIP uses for communication is 520. Lastly, looking at the RIP application data itself we see that this is a request message and we also see the metric as well as the version. A RIP request message is used by a router to tell other routers to send it the entire routing table. The metric of the request message type is 16 which is what it is supposed to be set according to the standard.

On R2, let’s go ahead and advertised the network to see what happens:




The layer 3 and layer 4 information should be similar to what I previously described before. Of importance is the RIP application data that we see above. This type of RIP message is a response and the address family is IP. When RIP was created they added this field so that the protocol could support other type of network protocol suites(AppleTalk, IPX, etc…). The last important field is the metric which has a value of 1. RIP uses hop count as a metric and this means that a router will always pick the route to a network that has the lowest hop count. In the case where the same network is being advertised by two different routers that have the same hop count then the local router will list two next hop addresses for the network in question. A Cisco router will then do load balancing between the two routes.

Let’s look at the results of the above command on R1:


The show IP protocols command tells us that this router is running RIP. We see that we can receive version 1 or 2 of RIP but we are only sending version 1 advertisements. It also shows us the network that we are routing for, i.e. those that we have advertised via the network command. Lastly, we see our two information sources which are R2 and R4 respectively since they are also advertising RIP networks to us. Of great importance here is the Distance which has a default value of 120. The administrative distance for a protocol tells you how believable that protocol is. The lower the administrative distance that a routing protocol has, the more believable it is. Protocols like OSPF(AD=110), EIGRP(AD=90), and IS-IS(AD=115) have lower administrative distances(AD) which means that if you receive the same route to a network using any of these other protocols then they will go into the routing table instead of the route that was learned via RIP due to a lower AD.

Looking at the routes on R1 we see the following:


We have learned of 1 route to the network via our neighbor on Fastethernet 0/0. We see that the AD=120 which is the default for RIP and also that it is 1 hop away from us. Let’s go ahead and advertised the same network from R4 to see what happens.



Now we have two ways to reach the same network and they are both in our routing table.

We are supposed to have network and attached to R1 so let’s go ahead and simulate these network via loopback interfaces.

R1(config)#interface loopback 3

R1(config-if)#ip address

R1(config-if)#no shutdown

Do the same for the other network. Let’s check to make sure that these network are up/up:


Both of them look good on our end so let’s go ahead and advertise them.


We only need one command to advertise both networks. RIPv1 is a classful protocol and therefor only takes the classful network address which in this case is the class B address. Looking at the packet capture from R1 for the port that connects to R2 we see the following:


Similarly on the interface from R1 that leads to R4:


Everything above seems correct and note that we don’t advertise the connected interface that our neighbors know about back to them. It doesn’t make sense to do this as they already know about it since they are directly connected.

Now that we have a basic rip configuration in place, let’s go ahead and upgrade our routers to send version 2 packets instead of version 1. RIPv2 allows for authentication, key management, route summarization, CIDR, and VLSM.

R1(config)#router rip

R1(config-router)#version 2

Do the above command on our neighbors as well so that they can send version 2 RIP advertisements. Let’s examine a RIPv2 advertisement to see what it looks like:


Starting at layer 3 we see that we are no longer using a broadcast address( to communicate. Instead we have switch over to the multicast address which reduces the amount of traffic on our network that is caused by RIP running. On the RIPv2 payload there have been a couple of additions made. The first is the route tag field that has a value of 0. The route tag is a parameter that is used to identify routes and we can tag routes that we redistribute(import from other routing protocols) into RIP so that we can tell them apart. We see the addition of a network mask field which allows RIPv2 to carry subnet information and hence being able to support CIDR. This makes RIPv2 a classless protocol whereas RIPv1 was classful. Lastly, we see a next hop field which is not used often and is almost always set to which means that any packets destined for this advertised network should be send to the router that advertised the network to you.

At this point in time we can go ahead and configure R3 as we did with the other routers. Make sure that you create the loopback interfaces and assign the IP addresses to each one. Also don’t forget to enable RIPv2 and advertise the network.

We can verify that everything is being learned via the routing table on R2:


At first everything seems fine but take a closer look at the network and the two ways to reach that network. We know from our diagram that the network is discontiguous and that R1 or R3 don’t own the entire range. Let’s try a ping from R2 to one of those networks to see what happens:


We can easily ping the network but not the network and in fact it is listed as being unreachable. The traceroute tells us that R2 is going to R1 to try to get to that network when in fact R1 is not connected to it. Let’s look at the advertisements that R2 is receiving to see what is going on:

From R1:


From R3:


We can see that both R1 and R3 are advertising the 172.16.1-4 networks using the classful address and therefore R2 thinks that they are both connected to the same network. By default, when RIPv2 is enabled routers will summarize networks to the classful address unless you turn off the feature. Let’s go ahead and turn this off on R1 and R3 via the following command:

R1(config-router)#no auto-summary

Let’s look at the advertisements again:

From R1:


From R3:


Since we turned off the auto summary feature, RIP is no longer summarizing the networks to the classful boundaries. Let’s look at the routing table on R2:


Everything looks good now since the routes are being advertised with /24 mask and each 172.16.1-4 network has the correct next hop address.

By default, RIPv2 will send and receive advertisements on any interface whose IP address matches a network that we are advertising. This means that R3 and R1 are both listening and sending advertisements on the 172.16.1-3 networks. If these networks don’t connect to another router but instead are only used to connect to end users then we can disable RIPv2 on those interfaces to increase the security. Let’s configure this on R1

R1(config-router)#router rip

R1(config-router)#passive-interface loopback 3

R1(config-router)#passive-interface loopback 4

We are using loopbacks interfaces for demonstration purposes but these could have easily been ethernet interfaces that connect to a switch.





The last thing that I will cover is the redistribution of static routes into RIP. R2 in our scenario connects to an ISP and I have configured a static default route on R2 so that all unknown traffic gets sent to our ISP.

R2(config)#ip route


From the show ip route command above, we now have a gateway of last resort listed to network and it has been marked as a Static Candidate Default(S*) route.

We can insert this static route into RIP via redistribution. The command below will redistribute all of the current static routes on R2 into RIP with a metric of 2. This means that our neighboring routers will get advertisements for these routes and add them to their respective routing tables.

R2(config-router)#redistribute static metric 2


Let’s take a look at R1 to see what his routing table is showing:


At the bottom we see that our static route has been advertised to our neighboring RIP routers. Alternatively, if we wanted to propagate this default static route to all our peers we could have also used the

R2(config-router)#default-information originate

command to achieve the same goal. The redistribute command is different in that not only does it propagate the default static route but it will also advertise any other static routes that we have configured on this device.

This concludes the above article and I hope that you found it useful. Going forward, I will put other articles up that will discuss other types of routing protocols. Thank you for reading this post and I hope to see you here next time.

One Response to “RIP Configuration Overview”

  1. sherlock says:

    very very helpful


  1. EIGRP Configuration Overview Part 1 | HIGHLNK - […] Moving onto layer 3 we see that our destination is a multicast IP address and in this case it…

Leave a Reply