RIP Intricacies

In studying for my CCIE R&S lab, I’ve decided to read through each and every configuration guide that applies to the R&S lab. To start the studying off, I decided to tackle a really easy subject: RIP. Yes, the age-old Router Information Protocol. RIP is practically older than half of the IT community, yet it’s still around (mainly for legacy support — or at least it should only be used for legacy support).

This article is about a few questions that my brain generated while reading the Cisco IOS 12.4 RIP Configuration Guide (http://www.cisco.com/en/US/docs/ios/iproute/configuration/guide/irp_cfg_info_prot_ps6350_TSD_Products_Configuration_Guide_Chapter.html).

BTW, if you’re not familiar with RIP, you might want to start with reading the actual RFC (RFC 1058) and reading the Cisco Configuration Guide (see the link above). There are a lot of great books out there that cover RIP as well. Suffice it to say, this article isn’t an intro to RIP, but rather focuses on some little known (at least to me, prior to this) intricacies of the protocol.

Before we begin…

For my examples, I have two routers: R1 and R2.  The relevant portions of the configs for each router are below.

R1

hostname R1
!
interface Loopback0
ip address 2.1.1.1 255.255.255.0
!
interface Serial0/0
ip address 1.2.2.1 255.255.255.0 secondary
ip address 1.3.3.1 255.255.255.0 secondary
ip address 1.1.1.1 255.255.255.0
serial restart-delay 0
clock rate 128000
!
router rip
version 2
network 1.0.0.0
network 2.0.0.0
no auto-summary
!

R2

!
hostname R2
!
interface Loopback0
ip address 3.3.3.1 255.255.255.0
!
interface Serial0/0
ip address 1.2.2.2 255.255.255.0 secondary
ip address 1.3.3.2 255.255.255.0 secondary
ip address 1.4.4.2 255.255.255.0 secondary
ip address 1.1.1.2 255.255.255.0
serial restart-delay 0
clock rate 128000
!
router rip
version 2
network 1.0.0.0
network 3.0.0.0
no auto-summary
!

RIP and Split-Horizon

I knew what Split-Horizon was for — don’t send an advertisement out of the interface it was received on.  Easy enough, right?

Well, what if there are secondary interfaces and you need to have RIP updates sourced from each IP address on the interface?  This can be accomplished by disabling split-horizon on the interface.  By disabling split-horizon, the router will source an update for each and every IP address on the interface — all primary and secondary IP addresses on the interface.

Here’s an example of the output from the debug ip rip command on R1 with split-horizon enabled on R2:

R1#debug ip rip
RIP protocol debugging is on
R1#
*Mar  1 00:31:41.127: RIP: received v2 update from 1.1.1.2 on Serial0/0
*Mar  1 00:31:41.131:      3.3.3.0/24 via 0.0.0.0 in 1 hops

Now take a look at the output from the same command on R1, with split-horizon disabled on R2′s S0/0 interface:

R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#int s0/0
R2(config-if)#no ip split-horizon


R1#
*Mar 1 00:29:24.931: RIP: received v2 update from 1.1.1.2 on Serial0/0
*Mar 1 00:29:24.935: 1.1.1.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:29:24.935: 1.2.2.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:29:24.939: 1.3.3.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:29:24.943: 1.4.4.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:29:24.947: 3.3.3.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:29:24.947: RIP: received v2 update from 1.2.2.2 on Serial0/0
*Mar 1 00:29:24.951: 1.1.1.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:29:24.955: 1.2.2.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:29:24.955: 1.3.3.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:29:24.959: 1.4.4.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:29:24.963: 2.1.1.0/24 via 0.0.0.0 in 2 hops
*Mar 1 00:29:24.967: 3.3.3.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:29:24.971: RIP: received v2 update from 1.3.3.2 on Serial0/0
*Mar 1 00:29:24.971: 1.1.1.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:29:24.975: 1.2.2.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:29:24.975: 1.3.3.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:29:24.979: 1.4.4.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:29:24.983: 2.1.1.0/24 via 0.0.0.0 in 2 hops
*Mar 1 00:29:24.987: 3.3.3.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:29:24.991: RIP: ignored v2 update from bad source 1.4.4.2 on Serial0/0
R1#

Source IP Address Validation

Notice in the above output that it complained about a “bad source” (1.4.4.2), yet it didn’t complain about any of the other secondary IP addresses?  This is because Cisco IOS routers by default do a sanity check on the source IP address of RIP updates.  The 1.1.1.0/24, 1.2.2.0/24 and 1.3.3.0/24 prefixes are configured on both routers, so R1 sees these source addresses as being “good sources”.  This is essentially a poor man’s uRPF check, or a very early version of this.  Essentially, if the source IP address shouldn’t be seen on an interface, it’s a “bad source”.

We can turn off this check by the following:


R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#router rip
R1(config-router)#no validate-update-source
R1(config-router)#end

Now let’s look at how R1 reacts to this “bad source” now that the validate-update-source feature is disabled:


R1#debug ip rip
RIP protocol debugging is on
R1#
*Mar 1 00:38:00.955: RIP: received v2 update from 1.1.1.2 on Serial0/0
*Mar 1 00:38:00.959: 1.1.1.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:38:00.959: 1.2.2.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:38:00.963: 1.3.3.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:38:00.967: 1.4.4.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:38:00.971: 3.3.3.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:38:00.971: RIP: received v2 update from 1.2.2.2 on Serial0/0
*Mar 1 00:38:00.975: 1.1.1.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:38:00.979: 1.2.2.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:38:00.979: 1.3.3.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:38:00.983: 1.4.4.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:38:00.987: 2.1.1.0/24 via 0.0.0.0 in 2 hops
*Mar 1 00:38:00.991: 3.3.3.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:38:00.995: RIP: received v2 update from 1.3.3.2 on Serial0/0
*Mar 1 00:38:00.995: 1.1.1.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:38:00.999: 1.2.2.0/24 via 0.0.
R1#0.0 in 1 hops
*Mar 1 00:38:00.999: 1.3.3.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:38:01.003: 1.4.4.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:38:01.007: 2.1.1.0/24 via 0.0.0.0 in 2 hops
*Mar 1 00:38:01.011: 3.3.3.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:38:01.015: RIP: received v2 update from 1.4.4.2 on Serial0/0
*Mar 1 00:38:01.015: 1.1.1.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:38:01.019: 1.2.2.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:38:01.023: 1.3.3.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:38:01.023: 1.4.4.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:38:01.027: 2.1.1.0/24 via 0.0.0.0 in 2 hops
*Mar 1 00:38:01.031: 3.3.3.0/24 via 0.0.0.0 in 1 hops
R1#

Wow! It doesn’t even care that 1.4.4.2 is essentially a bogus (could be a spoofed) source IP address…

It’s not recommended to turn this feature off — think of it more as a safety net — there when you need it. In my opinion, disabling the IP address source validation (validate-update-source) is something that’s more likely to appear in a lab scenario than real life.

To unicast or not to unicast — that is the question

One detail that I wasn’t sure about until my testing was whether or not specifying an interface as being passive would prohibit unicast neighbors from communicating.  Let’s find out (I already did, but will go through it again!)…

Here’s what we have to begin with:

R1#sho run | sec router rip
router rip
version 2
network 1.0.0.0
network 2.0.0.0
no auto-summary
R1#

And we see that we’re sending to 224.0.0.9:

R1#debug ip rip
RIP protocol debugging is on
R1#
*Mar 1 00:46:12.943: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (1.1.1.1)
*Mar 1 00:46:12.943: RIP: build update entries
*Mar 1 00:46:12.943: 2.1.1.0/24 via 0.0.0.0, metric 1, tag 0
R1#

Next, let’s make all of our interfaces passive:

R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router rip
R1(config-router)#pass def
R1(config-router)#

And we wait a little while (a minute should suffice — the default update timer is set to 30 seconds) and notice that we’re only receiving, not sending updates:

R1(config-router)#
*Mar 1 00:47:32.839: RIP: received v2 update from 1.1.1.2 on Serial0/0
*Mar 1 00:47:32.843: 3.3.3.0/24 via 0.0.0.0 in 1 hops
R1(config-router)#
*Mar 1 00:48:00.899: RIP: received v2 update from 1.1.1.2 on Serial0/0
*Mar 1 00:48:00.903: 3.3.3.0/24 via 0.0.0.0 in 1 hops
R1(config-router)#
*Mar 1 00:48:27.387: RIP: received v2 update from 1.1.1.2 on Serial0/0
*Mar 1 00:48:27.391: 3.3.3.0/24 via 0.0.0.0 in 1 hops
R1(config-router)#

Now, let’s go ahead and configure 1.1.1.2 as a unicast neighbor:

R1(config-router)#neighbor 1.1.1.2

And we notice the following shortly after entering this command:

R1(config-router)#
*Mar 1 00:49:05.011: RIP: sending v2 update to 1.1.1.2 via Serial0/0 (1.1.1.1)
*Mar 1 00:49:05.015: RIP: build update entries
*Mar 1 00:49:05.015: 2.1.1.0/24 via 0.0.0.0, metric 1, tag 0
R1(config-router)#

We are sending updates to the unicast neighbor, over our passive interface! The verdict from this test is that passive interfaces affect broadcast/multicast updates, but not unicast updates.

Also remember that passive interfaces affect outgoing updates only — inbound updates are received and processed on passive interfaces. If you must filter out incoming updates, either use a distribute-list or an offset-list (add 15 to the metric to ensure that incoming prefixes are always 16+ hops away).

Default Network Origination

Many Interior Gateway Protocols (IGPs) differ in how they can/will originate a default route. Compare EIGRP vs. OSPF in this respect — there are some significant differences that must be considered!

RIP is very forigiving in this respect. RIP can originate a default route in any of the following situations:

  • Use the ip default-network command
  • Use the default-information originate command
  • Learn a default route from some other source (static route or from another routing protocol, then redistribute this route into RIP)

This is a lot easier to deal with than the caveats of EIGRP and OSPF (please, don’t use RIP at home, at work or any other place if possible).  I’m not advocating RIP at this point, just stating that it’s very flexible in this respect.

Cisco-Specific RIP Timer

If you’re asked, the holddown timer is Cisco-specific, as it’s not defined in the RFC.

Those Efficient Summary Routes

We’re all aware of the benefits of summary routes, however RIP offers another benefit: according to Cisco documentation (see the link above), summary routes in the RIP database are processed first (ie. before the multiple individual routes).  For this reason, summary routes can be seen as being more efficient than multiple individual routes (besides the fact of less memory and CPU consumption from more routes needing to be processed without using summary routes, etc.).

Summary routes use the lowest (best) metric from all of the summarized prefixes.

There are some caveats about summary routes — look at the above Cisco article for the details.  Ultimately, using auto-summary isn’t inline with industry best-practices, so I won’t bother going into the details about auto-summary versus manual summary routes (which one wins when both are configured).

Conclusion

Hopefully this has been of some help.  RIP is still in existence today and is a listed topic on the CCIE R&S lab exam, so being aware of the little details of how RIP works is essential.  As far as real-world use, RIP is past it’s prime and shouldn’t be used — select a more robust IGP (OSPF, EIGRP, etc.) in leui of RIP whenever possible.

‘Til next time… keep on routing!

Leave a Reply

Your email address will not be published.

HTML tags are not allowed.

WordPress Themes