RIP Justification

A group of engineers and I were having a design discussion about routing
protocols including RIP and static routing and the justifications of use for
each protocol. One very interesting discussion was surrounding RIP and its
use versus a protocol like OSPF. It seems that many Network Engineers
consider RIP an old antiquated protocol that should be thrown in back of a
closet "never to be seen or heard from again". Some even preferred using a
more complex protocol like OSPF instead of RIP. I am of the opinion that
every protocol has its place, which seems to be contrary to some engineers
way of thinking. This leads to my question. What are your views of when and
where the RIP protocol is useful? Please excuse me if this is the incorrect
forum for such questions.

RIP has one property no "modern" protocol has. It works on simplex links (e.g. high-speed satellite downlink with low-speed terrestrial uplink).

Is that useful? I don't know, but it is still a fact.

I would think it would depend on the complexity of the network and how the
network advertises routes to peer networks. I'm always in favor the simpler
the better but with RIP you do lose the ability to use variable bit masks
(CIDR) and faster routing algorithms like DUAL used in Cisco routers and I'm
not a big fan of OSPF.

Gary

IPVPN arrangement with multiple sites & no redundancy for each small site.
RIP to advertise networks from each site towards cloud, quick and easy.

Loss of using VLSM's is a big thing to give up.

You can go to RIPv2 and get that however. Would work for small networks to
stay under the hop-count limit as it is still distance-vector.

RIPv2 is a great dynamic routing protocol for exchanging routes with
untrusted networks. RIPv2 has adjustable timers, filters, supports VLSM and
MD5 authentication. Since it's distance vector it's much easier to filter
than a protocol that uses a link state database that must be the same across
an entire area.

Chris

I would think most people using RIP with IPv4 would use RIPv2 which does
allow CIDR.

A group of engineers and I were having a design discussion about routing
protocols including RIP and static routing and the justifications of use for
each protocol. One very interesting discussion was surrounding RIP and its
use versus a protocol like OSPF. It seems that many Network Engineers
consider RIP an old antiquated protocol that should be thrown in back of a
closet "never to be seen or heard from again". Some even preferred using a
more complex protocol like OSPF instead of RIP. I am of the opinion that
every protocol has its place, which seems to be contrary to some engineers
way of thinking. This leads to my question. What are your views of when and
where the RIP protocol is useful? Please excuse me if this is the incorrect
forum for such questions.

I'd argue that in order to do anything useful (read: moderately sized) with RIP (aside from supporting legacy devices lacking anything else and as Patrick mentioned handling asymmetric links), you actually need to _add_ complexity in order to make it work –– if you can at all. The lack of path vectoring limits network diameter due to counting to infinity, redundancy requires the use of hold down timers (which are proportionate to the diameter of the network), etc.

Antilock brakes are "complex" from an mechanical perspective. But the act of braking is the same. Turn on the protocol. Add the necessary interfaces. Subnet accordingly. Summarize where possible. Walk away.

"Let the machines do the work." -Vijay Gill (most recently as I recall)

C

(I assume "RIP" above refers to RIPv2.)

When the automobile was developed, plenty of folks thought horses were
obsolete and would fall completely out of use. However, the reality is
that there are still some things horses are better at, e.g. terrain that
automobiles (even 4WD) simply can't navigate, places where automobiles
are banned for safety, aesthetic and/or environmental reasons, etc.

Newer isn't always better.

S

That is the correct way to think about RIP. (RIPv1 specific) In 99% of the cases where I've seen RIP used (over 2 decades), they would've been better off with static routes. (or they needed something a lot more complex/robust... say, a power company running RIPv1 over their entire network.) The 1% where it was a necessary evil... dialup networking where the only routing protocol supported was RIP (v2) [netblazers] -- static IP clients had to be able to land anywhere -- but RIP only lived on the local segment, OSPF took over network-wide. (Later MaxTNT's were setup with OSPF stub areas so they didn't have to have a full route table.)

BTW, ALL other routing protocols are more complex than RIP. One cannot get any simpler than RIP.

--Ricky

Jesse - just to clarify, are you talking about v1 or v2? There is also
a proposal for v3..
In my previous post, I was assuming v2.

I remember RIP across chassis for the TotalControl bonded dialup stuff, and as you mention, static IPs, but I haven't seen it in serious use for a long time.

Cheers,
-j

For RIP, the attraction is simplicity, and the down-side is count-to-infinity. If you have a network in which count-to-infinity is a non-issue - often true of residential networks, for example - the simplicity of RIP can be very attractive.

If you have anything resembling complexity in your network, protocols like OSPF are far more appropriate.

I am referring to RIPv2

I see nothing wrong with using RIPV2 for small networks as it is more dynamic and faster convergence.
As for RIPv1, I think we can all say, RIP!! (no pun intended) Ok yes it was intended.... LOL...

I think some engineers get lost in the "whatever is newer is better" and you don't need to use a complicated
protocol for small simple networks. Now, you should think ahead if that's possible and if you do know it can
get complicated, you can implement the right protocol from the start.

I have not heard about RIPv3. I suppose I should start looking into it......

We have a design for our wan where we use rip v2 and it works very well, we were using ospf but it was additional config, so in our case simple was better, and it works well..

I could discuss it more with you off-line if you like.

Thus spake Jesse Loggins (jlogginsccie@gmail.com) on Wed, Sep 29, 2010 at 01:20:48PM -0700:

This leads to my question. What are your views of when and
where the RIP protocol is useful?

I most often see RIPv2 used simply to avoid paying vendor license fees to run
more sophisticated things such as OSPF.

Dale

The good thing about vendors who charge license fees to run more sophisticated things such as OSPF is that there are always other vendors out there who don't charge license fees for bread and butter protocols - such as OSPF.

Nick

RIP is useful as an edge protocol where there is a single access - less system overhead than OSPF.
The service provider and the customer can redistribute the routes into whatever routing protocol they use in their own networks.

Jonathon

> where the RIP protocol is useful? Please excuse me if this is the =
incorrect
> forum for such questions.

RIP has one property no "modern" protocol has. It works on simplex =
links (e.g. high-speed satellite downlink with low-speed terrestrial =
uplink).

Is that useful? I don't know, but it is still a fact.

I once had cause to write a RIP broadcast daemon while on-site with a
client; they had some specific brokenness with a Novell server and some
other gear that was "fixed" by a UNIX box, a C compiler, and maybe 20
or 30 minutes of programming (mostly to remember the grimy specifics of
UDP broadcast programming). I do not recall the specific routing issue,
but being able to just inject a periodic "spoofed" packet was sufficient
to repair them.

While not the correct way to engineer a network, sometimes being able to
bring a client's network back on-line in a crisis is more important than
technical correctness. I feel reasonably certain that I would not have
been able to cobble together a quick solution if they had been relying
on OSPF, etc. A simple protocol can be a blessing. I concede it is more
often a curse.

... JG