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…
There are quite a few other RIP configuration items available…
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…
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…
RIP Updates
If we take a look at our topology again…
We can examine the multicast route updates occurring between switch1 and router4…
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…
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…
On the other hand, router4 can really only tell switch1 about the prefixes that it isn’t hearing directly from switch1…
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…
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.
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…
Now let’s check out our RIP database and see what we have…
Odd, it isn’t there. Checking the FIB we see that the prefix is present on the EIGRP side of things…
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…
There’s our problem! To fix this, we need to tell RIP what metric to use when redistributing the EIGRP routes…
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…
Router3 shows that it has the route with a metric of 15…
So there you have it, a quick and dirty look at RIP!