RIP – The all in one post

      No Comments on RIP – The all in one post

There are a few versions of RIP out there…

RIPv1 – The original standard

RIPv2 – The original standard with a few additions that include…
-Support for classless routing
-Authentication
-Next hop address in route update
-Multicast route updates
-External tagging

RIPng – RIPv2 with the addition of support for IPv6

Since we haven’t talked about IPv6 yet, we are going to focus on RIPv2 in this post. 

RIP Updates
One of the huge improvements in RIPv2 is how the RIP updates are sent.  In RIPv1, the updates were broadcast across the network.  This meant that all routers ,even those not concerned with RIP, had to take the time to look at the packet before deciding not to use it.  In RIPv2, updates are multicast to the address 224.0.0.9. 

RIP Basic configuration
The configuration of RIP is brilliantly easy.  Much like any other IGP that we’ve examined, you simply define the routing protocol, set the version, and pick the networks you want to be advertised…

image

There are quite a few other RIP configuration items available…

image 

However, we should be pretty comfortable with most of these by now.  Rather than showing the configuration of these items, I’d like to talk about the RIP database followed by a basic redistribution example.

Unlike OSPF and EIGRP, the RIP database doesn’t have much to it.  In fact, there really aren’t many ‘show’ command for RIP at all…

image

As you can see, the only ‘show’ command it the ‘show ip rip database’ command.  On top of that, the only extension to that command allows you to look at a specific prefix.   And even when you do that, there isn’t anything more to look at…

image

RIP Updates
If we take a look at our topology again…

image

We can examine the multicast route updates occurring between switch1 and router4…

image

Here we see router4 advertising out it’s updates to switch1.  Note the multicast destination address and that router4 is only advertising the prefixes 10.0.0.20/30 and 10.0.0.0/24 prefix.  On the other hand, if we look at switch1’s update…

image

We see it advertising quite a few prefixes down to router4.  Why the difference in prefix count?  Basic split-horizon rules are applying here.  Switch1 is telling router4 about prefixes that it did NOT hear about directly from router4.  Those would include the following highlighted links…

image

On the other hand, router4 can really only tell switch1 about the prefixes that it isn’t hearing directly from switch1…

image

Keep in mind, that this really only applies to the ‘winning’ route here.  RIP uses the hop count as the metric and considers 16 to be ‘infinite’.  That is, a router that is 16 hops away wont be considered by RIP.  So in this case, router4’s best path to 10.0.0.24/30 is through router2 which implies that it heard the update from router2.  We can confirm that by looking at the communication between router2 and router4…

image

Above, router2 tells router4 about the path to 10.0.0.24/30. 

Below, since router4 is using that path for the prefix 10.0.0.24/30, there is no need to tell router2 about that prefix in it’s reply.

image

Switch1’s best path to 10.0.0.24/30 is through router1 so it obviously heard that update through router1.  This being said, since the best path to the 10.0.0.24/30 prefix for each device is through a different device, the devices can safely tell each other about the best path they have to 10.0.0.24/30.  If the link between router2 and router4 broke, router4 would stop sending switch1 the update for 10.0.0.24/30 since router4’s best path to that prefix would be through switch1. Don’t tell a device about the pest path to a prefix if it’s back through the same device.

It should be obvious at this point that RIP is just periodically sending it’s entire route table as an update to it’s neighbors.  There is no concept of a initial full update and then just minor updates afterwards.

RIP Redistribution
Let’s take a look at redistributing out 192.168.0.0/16 prefix from switch3 into RIP on switch2.  Recall that switch2 and 3 area talking EIGRP.  That being said, we want to redistribute EIGRP into RIP.  Let’s give that a try on switch2 and see what happens…

image

Now let’s check out our RIP database and see what we have…

image

Odd, it isn’t there.  Checking the FIB we see that the prefix is present on the EIGRP side of things…

image

So what could the problem be?  Recall above that I said the max metric for RIP was 16?  Take a look at the EIGRP route metric in the FIB…

image

There’s our problem!  To fix this, we need to tell RIP what metric to use when redistributing the EIGRP routes…

image

Now, since we set it to 13, the prefix will only appear on routers 6, 5, and 3.  Once it gets to router3 the metric will be 15 and switch1 will reject the route…

image

Router3 shows that it has the route with a metric of 15…

image

So there you have it, a quick and dirty look at RIP!

Leave a Reply

Your email address will not be published.